Содержание статьи
Начиная с Server 2008 и Vista в винду был встроен механизм WFP,
представляющий собой набор API и системных сервисов. С помощью него стало можно
запрещать и разрешать соединения, управлять отдельными пакетами. Эти
нововведения были предназначены для упрощения жизни разработчиков различных
защит. Внесенные в сетевую архитектуру изменения затронули как kernel-mode, так
и user-mode части системы. В первом случае необходимые функции экспортируются
fwpkclnt.sys, во втором — fwpuclnt.dll (буквы "k" и "u" в названиях библиотек
означают kernel и user соответственно). В этой статье мы расскажем о применении
WFP для перехвата и фильтрации трафика, а после ознакомления с основными
определениями и возможностями WFP мы напишем свой простой фильтр.
Основные понятия
Перед началом кодинга нам совершенно необходимо ознакомиться с терминологией
Microsoft — и для понимания статьи будет полезно, и дополнительную литературу
читать будет проще :). Итак, поехали.
Классификация — процесс определения того, что нужно делать с пакетом.
Из возможных действий: разрешить, блокировать или вызвать callout.
Callouts — это набор функций в драйвере, которые проводят инспекцию
пакетов. Они имеют специальную функцию, выполняющую классификацию пакетов. Эта
функция может принять следующее решение:
- разрешить (FWP_ACTION_PERMIT);
- блокировать (FWP_ACTION_BLOCK);
- продолжить обработку;
- запросить больше данных;
- прервать соединение.
Фильтры (Filters) — правила, указывающие, в каких случаях вызывается
тот или иной callout. Один драйвер может иметь несколько callout’ов, а
разработкой драйвера с callout’ом мы и займемся в этой статье. Кстати, колауты
есть и встроенные, например, NAT-callout.
Layer — это признак, по которому объединяются различные фильтры (или,
как говорят в MSDN, "контейнер").
По правде говоря, документация от Microsoft, выглядит достаточно мутно, пока
не заглянешь в примеры в WDK. Поэтому, если вдруг надумаешь разрабатывать что-то
серьезное, нужно непременно с ними ознакомиться. Ну что ж, теперь плавно
перейдем к практике. Для успешной компиляции и тестов тебе потребуется WDK (Windows
Driver Kit), VmWare, виртуальная машина с установленной Вистой и отладчик WinDbg.
Что касается WDK, то у меня лично установлена версия 7600.16385.0 — там есть все
необходимые либы (поскольку мы будем разрабатывать драйвер, нам нужны только
fwpkclnt.lib и ntoskrnl.lib) и примеры использования WFP. Ссылки на весь
инструментарий уже неоднократно приводились, поэтому повторяться не будем.
Coding
Для инициализации callout’а я написал функцию BlInitialize. Общий алгоритм
создания callout и добавления фильтра таков:
- FWPMENGINEOPEN0 осуществляет открытие сеанса;
- FWPMTRANSACTIONBEGIN0 — начало операции с WFP;
- FWPSCALLOUTREGISTER0 — создание нового callout;
- FWPMCALLOUTADD0 — добавление объекта callout’а в систему;
- FWPMFILTERADD0 — добавление нового фильтра(ов);
- FWPMTRANSACTIONCOMMIT0 — сохранение изменений (добавленных
фильтров).
Обрати внимание, что функции оканчиваются на 0. В Windows 7 некоторые из этих
функций были изменены, например, появилась FwpsCalloutRegister1 (при
сохраненной FwpsCalloutRegister0). Отличаются они аргументами и, как следствие,
прототипами классифицирующих функций, но для нас это сейчас неважно — 0-функции
универсальны.
FwpmEngineOpen0 и FwpmTransactionBegin0 не особо нам интересны — это
подготовительный этап. Самое интересное начинается с функции
FwpsCalloutRegister0:
Прототип FwpsCalloutRegister0
NTSTATUS NTAPI FwpsCalloutRegister0
(
__inout void *deviceObject,
__in const FWPS_CALLOUT0 *callout,
__out_opt UINT32 *calloutId
);
Я уже говорил, что callout — это набор функций, теперь пришло время
рассказать об этом подробнее. Структура FWPS_CALLOUT0 содержит указатели на три
функции — классифицирующую (classifyFn) и две уведомляющие (о
добавлении/удалении фильтра (notifyFn) и закрытии обрабатываемого потока (flowDeleteFn)).
Первые две функции являются обязательными, последняя нужна только в случае, если
ты хочешь мониторить сами пакеты, а не только соединения. Также в структуре
содержится уникальный идентификатор, GUID колаута (calloutKey).
Код регистрации callout
FWPS_CALLOUT sCallout = {0};
sCallout.calloutKey = *calloutKey;
sCallout.classifyFn = BlClassify;
// классифицирующая функция
sCallout.notifyFn = (FWPS_CALLOUT_NOTIFY_FN0)BlNotify;
// функция, уведомляющая о добавлении/удалении фильтра
// создаем новый колаут
status = FwpsCalloutRegister(deviceObject, &sCallout, calloutId);
Далее нужно добавить объект-callout в систему и присоединить его к
определенному уровню (layer) с помощью функции FwpmCalloutAdd0:
DWORD WINAPI FwpmCalloutAdd0(
__in HANDLE engineHandle,
__in const FWPM_CALLOUT0 *callout,
__in_opt PSECURITY_DESCRIPTOR sd,
__out_opt UINT32 *id
);
typedef struct FWPM_CALLOUT0_ {
GUID calloutKey;
FWPM_DISPLAY_DATA0 displayData; // описание callout
UINT32 flags;
GUID *providerKey;
FWP_BYTE_BLOB providerData;
GUID applicableLayer;
UINT32 calloutId;
} FWPM_CALLOUT0;
В структуре FWPM_CALLOUT0 нам интересно поле applicableLayer — уникальный
идентификатор уровня, на который добавляется callout. В нашем случае это
FWPM_LAYER_ALE_AUTH_CONNECT_V4. "v4" в названии идентификатора означает версию
протокола Ipv4, есть также FWPM_LAYER_ALE_AUTH_CONNECT_V6 для Ipv6. Учитывая
малую распространенность Ipv6 на настоящий момент, работать мы будем только с
Ipv4. CONNECT в названии означает, что мы контролируем только установку
соединения, о входящих и исходящих на этот адрес пакетах речи не идет! Вообще
уровней, помимо использованного нами, много — они объявлены в заголовочном файле
fwpmk.h из WDK.
Добавление объекта-callout в систему
// название callout
displayData.name = L"Blocker Callout";
displayData.description = L"Blocker Callout";
mCallout.calloutKey = *calloutKey;
mCallout.displayData = displayData;
// описание callout
//FWPM_LAYER_ALE_AUTH_CONNECT_V4
mCallout.applicableLayer = *layerKey;
status = FwpmCalloutAdd(gEngineHandle, &mCallout, NULL, NULL);
Итак, после того, как callout успешно добавлен в систему, нужно создать
фильтр, то есть указать, в каких случаях будет вызываться наш callout, а именно
— его классифицирующая функция. Новый фильтр создается функцией FwpmFilterAdd0,
которой в качестве аргумента передается структура FWPM_FILTER0.
В FWPM_FILTER0 есть одна или несколько структур FWPM_FILTER_CONDITION0 (их
число определяется полем numFilterConditions). Поле layerKey заполняется GUID’ом
уровня (layer), к которому мы хотим присоединиться. В данном случае указываем
FWPM_LAYER_ALE_AUTH_CONNECT_V4.
Теперь подробнее рассмотрим заполнение FWPM_FILTER_CONDITION0. Во-первых, в
поле fieldKey нужно явно указать, что мы хотим контролировать — порт, адрес,
приложение или что-то еще. В данном случае WPM_CONDITION_IP_REMOTE_ADDRESS
указывает системе, что нас интересует IP-адрес. Значение fieldKey определяет,
значения какого типа будут в структуре FWP_CONDITION_VALUE, входящей в
FWPM_FILTER_CONDITION0. В данном случае в ней содержится ipv4-адрес. Идем
дальше. Поле matchType определяет, каким образом будет производиться сравнение
значения в FWP_CONDITION_VALUE с тем, что пришло по сети. Тут вариантов много:
можно указать FWP_MATCH_EQUAL, что будет означать полное соответствие условию, а
можно — FWP_MATCH_NOT_EQUAL, то есть, фактически, мы можем добавить таким
образом исключение фильтрации (адрес, соединение с которым не отслеживается).
Еще есть варианты FWP_MATCH_GREATER, FWP_MATCH_LESS и другие (см. энум
FWP_MATCH_TYPE). В данном случае у нас стоит FWP_MATCH_EQUAL.
Я не стал сильно заморачиваться и просто написал условие на блокирование
одного выбранного IP-адреса. В случае, когда какое-то приложение попытается
установить соединение с выбранным адресом, будет вызвана классифицирующая
функция нашего callout’а. Код, обобщающий сказанное, ты можешь посмотреть на
врезке "Добавление фильтра в систему".
Добавление фильтра в систему
filter.flags = FWPM_FILTER_FLAG_NONE;
filter.layerKey = *layerKey;
filter.displayData.name = L"Blocker Callout";
filter.displayData.description = L"Blocker Callout";
filter.action.type = FWP_ACTION_CALLOUT_UNKNOWN;
filter.action.calloutKey = *calloutKey;
filter.filterCondition = filterConditions;
// одно условие фильтрации
filter.numFilterConditions = 1;
//filter.subLayerKey = FWPM_SUBLAYER_UNIVERSAL;
filter.weight.type = FWP_EMPTY; // auto-weight.
// добавляем фильтр на удаленный адрес
filterConditions[0].fieldKey = FWPM_CONDITION_IP_REMOTE_ADDRESS;
filterConditions[0].matchType = FWP_MATCH_EQUAL;
filterConditions[0].conditionValue.type = FWP_UINT32;
filterConditions[0].conditionValue.uint32 = ntohl(BLOCKED_IP_ADDRESS);
// добавляем фильтр
status = FwpmFilterAdd(gEngineHandle, &filter, NULL, NULL);
Вообще, конечно, фильтрующих условий может быть много. Например, можно
указать блокирование соединений с определенным удаленным или локальным портом (FWPM_CONDITION_IP_REMOTE_PORT
и FWPM_CONDITION_IP_LOCAL_PORT соответственно). Можно вылавливать все пакеты
определенного протокола или определенного приложения. И это еще не все! Можно,
например, заблокировать трафик определенного пользователя. В общем, есть где
разгуляться.
Впрочем, вернемся к фильтру. Классифицирующая функция в нашем случае просто
блокирует соединение с указанным адресом (BLOCKED_IP_ADDRESS), возвращая
FWP_ACTION_BLOCK:
Код нашей classify-функции
void BlClassify(
const FWPS_INCOMING_VALUES* inFixedValues,
const FWPS_INCOMING_METADATA_VALUES* inMetaValues,
VOID* packet,IN const FWPS_FILTER* filter,
UINT64 flowContext,FWPS_CLASSIFY_OUT* classifyOut)
{
// заполняем структуру FWPS_CLASSIFY_OUT0
if(classifyOut){ // блокируем пакет
classifyOut->actionType =
FWP_ACTION_BLOCK;
// при блокировании пакета нужно
сбрасывать FWPS_RIGHT_ACTION_WRITE
classifyOut->rights&=~FWPS_RIGHT_ACTION_WRITE;
}
}
На практике функция классификации также может установить FWP_ACTION_PERMIT,
FWP_ACTION_CONTINUE и др.
И в заключение при выгрузке драйвера нужно удалить все установленные
callout’ы (угадай, что будет, если система попытается вызвать callout
выгруженного драйвера? Правильно, BSOD). Для этого существует функция
FwpsCalloutUnregisterById. В качестве параметра ей передается 32-битный
идентификатор callout’а, возвращенный функцией FwpsCalloutRegister.
Завершение работы callout’а
NTSTATUS BlUninitialize(){
NTSTATUS ns;
if(gEngineHandle){
FwpmEngineClose(gEngineHandle);
}
if(gBlCalloutIdV4){
ns =FwpsCalloutUnregisterById(gBlCalloutIdV4);
}
return ns;
}
Как видишь, программирование WFP-фильтра — не такая сложная задача, поскольку
MS предоставили нам весьма удобный API. Кстати, в нашем случае мы устанавливали
фильтр в драйвере, но это можно делать и из юзермода! Например, семпл из wdk
msnmntr (монитор трафика MSN Messenger-а) так и поступает — это позволяет не
перегружать kernel-mode часть фильтра.
Свой GUID
Для регистрации callout ему нужен уникальный идентификатор. Для того, чтобы
получить свой GUID (Globally Unique Identifier), используй guidgen.exe, входящий
в Visual Studio. Лежит тулза в (VS_Path)\Common7\Tools. Вероятность коллизии
очень мала, поскольку длина GUID составляет 128 бит, и всего доступно 2^128
идентификаторов.
Отладка фильтра
Для отладки дров удобно использовать связку Windbg+VmWare. Для этого нужно
настроить как гостевую систему (в виде которой выступает Vista), так и отладчик
WinDbg. Если у WinXP для удаленной отладки нужно было редактировать boot.ini, то
для Vista+ есть консольная утилита bcdedit. Как обычно, нужно включить отладку:
BCDedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200 BCDedit /debug
ON (или BCDedit /set debug ON)
Далее нужно настроить последовательный порт удаленной системы (см.
соответствующую иллюстрацию).
Теперь все готово! Запускаем батник с нижеприведенным текстом:
start windbg -b -k com:pipe,port=\\.\pipe\com_1,resets=0
и лицезреем отладочный вывод в окне windbg (см. картинку).
Заключение
Как видишь, область применения WFP довольно широка. Тебе решать, как
применить эти знания — во зло или во благо 🙂