Фильтрация сетевого трафика с домейнами

Как то давно игрался с фильтрацией сетевого трафика. Для ХР написал драйвер фильтр ТСР (точнее Firewall-Hook), для Висты и Семерки - есть юзермодный API (WFP). Но мои фильтры были ограничены IP уровнем. То есть, получаем пакет, и по его IP адресу "решаем его судьбу". А как бы делать фильтрацию по domain адресу? Неужели нужно самостоятельно "потрошить" пакеты вытаскивая из них необходимую информацию?

 

Фильтрация чего имеется в виду - DNS, SMB, HTTP или что-то ещё? Впрочем, на самом деле, это не сильно важно, т.к. система не предоставляет никаких встроенных средств для фильтрации протоколов прикладного уровня. А если нужно проверить домен, к которому относится IP-адрес в перехваченном пакете, ну так это без особых проблем даже в TDI-фильтре можно сделать через собственный DNS-запрос (начиная с Windows 7 в ядре даже есть соответствующие вызовы).

 

Имеется ввиду фильтрация http.

A как делать до семерки? Ручками?

 

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

Да, вручную слать соответствующие DNS-запросы, не так уж и сложно. Ну или перенаправлять запрос в UM, где звать DnsQuery().

 

А есть ли возможность в WPF делать фильтрацию по domain адресу на user-mode уровне? Как понимаю нет, верно? Где-б найти "отправную точку" для WPF драйвер фильтра?

P.S. кстати, нет ли "готовых" реализаций файрволов для интеграции в собственный проект?

 

Насколько я знаю, - нет.

Здесь документация.
Здесь форум, можно вопросы задавать.
Ну и в комплекте WDK есть сэмплы для WFP.

Есть, почему же нет, правда, достаточно убогие, как по мне, и, разумеется, платные. Для примера, есть вот такое, также есть SDK просто для сетевой фильтрации, например, этот или этот.

 

x64
спасибо, буду копать.

Кстати, какие преимущества перед NDIS дает WFP?

 

Удобство, доступ к контексту операции и т.д.
Но вообще это вещи, предназначенные для разных задач.

 

Кстати, можно ли сделать фильтр на на пакеты а на DNS запросы? Не будет ли это проще фильтрации пакетов?

 

В контексте задачи о фильтрации HTTP-запросов это вообще не имеет смысла.

 

Поставил фильтр на FWPM_LAYER_ALE_AUTH_CONNECT_V4. В калбеке извлекаю из layerData payload.

Код (Text):

1. NdisAdvanceNetBufferDataStart(...)
2. payload = (PBYTE)NdisGetDataBuffer(...);

Содержимое payload'а, что называется "видит глаз да зуб неймет". Вижу, по дампу памяти, что он содержит информацию о url прямо в текстовом виде, но формат этого payload для меня остается загадкой. Документация в msdn довольно туманна

Вроде этот payload должен содержать IP_HEADER. Но судя по его содержимому - не похоже.

P.S. Фух, разобрался, payload содержит непосредственно DNS запрос.

 

Начал реализовывать DNS фильтр на TDI. Написал обработчик TDI_SEND для UDP. Ловлю интересующие DNS запросы и пытаюсь заблокировать DNS resolution просто прерывая обработку irp, т.е.,

Код (Text):

1.  
2. irp->IoStatus.Status = STATUS_NETWORK_BUSY;
3. irp->IoStatus.Information = 0;
4. IoCompleteRequest(irp, IO_NO_INCREMENT);
5. return STATUS_SUCCESS;

А страница в браузере все равно загружается (кеш почистил). Чешу мозг, как такое может быть?

 

TDI_SEND_DATAGRAM

Кэш броузера не имеет никакого отношения к DNS-резолвингу.

 

Странно, ловлю TDI_SEND_DATAGRAM. Элемнтарный код:

Код (Text):

1. if (stack->MinorFunction == TDI_SEND_DATAGRAM)          {
2.     PTDI_REQUEST_SEND_DATAGRAM send = (PTDI_REQUEST_SEND_DATAGRAM)&irpStackLocation->Parameters;

Содержимое send - полный бред. Например send->SendDatagramInformation.UserData=0 и send->SendDatagramInformation.UserDataLength=0x12320771.

Притом, в дампе send ясно видно что пакет верный и содержит dns запрос.

Код (Text):

1. 81b55b2c  19 00 00 00 00 5c b5 81-00 00 00 00 00 00 00 00  .....\..........
2. 81b55b3c  68 fd ea 81 70 cb df 81-b8 b5 f7 f6 00 5c b5 81  h...p........\..
3. 81b55b4c  00 00 00 00 20 00 04 00-00 00 00 00 80 5b b5 81  .... ........[..
4. 81b55b5c  00 50 b5 81 19 00 00 00-80 0b 00 00 55 1f 00 00  .P..........U...
5. 81b55b6c  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
6. 81b55b7c  00 00 00 00 8b c9 01 00-00 01 00 00 00 00 00 00  ................
7. 81b55b8c  04 77 61 73 6d 02 72 75-00 00 01 00 01 00 00 00  .wasm.ru........
8. 81b55b9c  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

В интернете удивительно мало примеров обработки TDI_SEND_DATAGRAM.

 

Нужно больше кода. И структура TDI_REQUEST_SEND_DATAGRAM - левая (сам объявил?), следует использовать предопределённую TDI_REQUEST_KERNEL_SENDDG.

 

x64
Большое спасибо! TDI_REQUEST_KERNEL_SENDDG подходит.


TDI_REQUEST_SEND_DATAGRAM есть в ДДЛ 7600.

 

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

 

C2H5OH
Спасибо за напоминание. На самом деле на данном этапе это всего-лишь "proof of concept". В реальном приложении буду "заворачивать" трафик не так брутально.

Кстати, как можно отличить DNS запросы? Ведь они только "в книгах" идут на UDP:53. В "дикой природе" встречаются NDS запросы как на порт отличный от 53, так и по TCP вместо UDP. Потециально, можно анализировать содержимое датаграм вылавливая что то похожее на формат DNS. Но такая эвристика весьма ненадежна.

 

Лолшто?

Что за ересь?!

 

x64

Если ты, о великий гуру низкоуровнего кодинга, не знаешь про проблемы синхронизации отмены, то иди лучше кукурузу охраняй. Ну или в лучшем случае можешь попробовать себя в SEO, у тебя блоги неплохо получается раскручивать
Более подробнее об отмене IRP'ов и возникающих с этим проблемах почитай у Оуни, что ли, он хорошо ее расписывает, начиная с 260-страницы.
Ну и последний гвоздь напоследок -

Оnly for you, официальная ересь от microsoft:
1) http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/cancel_logic.doc
2) http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/FTdrv.doc
3) http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/IoCsqArt.doc

checkmate