Доброго времени суток.
Есть система. В нее приходят сообщения по протоколу (скажем SMTP или POP3). Мне нужно получить их содержимое до того как они дойдут до приложения, которому отправлены. Данную задачу необходимо решить с помощью Winsock. Базовыми знаниями Winsock обладаю. Но идей на счет того КАК контролировать ВЕСЬ трафик по определенному порту пока нет. Может кто подскажет?

Здравствуйте, Аноним, Вы писали:

А>Есть система. В нее приходят сообщения по протоколу (скажем SMTP или POP3). Мне нужно получить их содержимое до того как они дойдут до приложения, которому отправлены. Данную задачу необходимо решить с помощью Winsock. Базовыми знаниями Winsock обладаю. Но идей на счет того КАК контролировать ВЕСЬ трафик по определенному порту пока нет. Может кто подскажет?

Главный вопрос.
Что значит контролировать трафик ? Просто мониторинг подойдет, или задача сводится к тому,
чтобы "резать" или подменять определенные данные ?

Отвечу пока так — ставьте перехватчики на функции Winsock (а также кое-какие еще) во всех
процессах и сможете видеть все, что идет по сети.

Хотя для коммерческих проектов метод так себе, мягко говоря.

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

Во-вторых, программы вроде Skype могут быть достаточно защищены от инжекта и
просто не дадут хукать функции в своих адресных пространствах.
Вспомните еще про UPX, VmProtect и всякие политики безопасности в Vista и выше.

В-третьих, техника перехвата API сама по себе достаточно сложна.
На красивые термины "сплайсинг" и "инжект" покупается только молодняк, а
опытные бегут от них как от чумы. И если в системе будет установлен такой же хук, —
к примеру, с помощью Detours, — то скорее всего, сеть вообще повиснет.

Если надо действительно нормальное решение, которое работает почти везде,
советую смотреть на TDI/LSP/WFP. Иных вариантов попросту не существует.

Здравствуйте, okman, Вы писали:

O>Главный вопрос.
O>Что значит контролировать трафик ? Просто мониторинг подойдет, или задача сводится к тому,
O>чтобы "резать" или подменять определенные данные ?

Это курсовой проект. Цель: фильтр почты. На проекте несколько человек. Моя задача перехватить сообщение и отправить на анализ (за анализ отвечает другогой человек). В результате он сообщает можно или нельзя чтобы оно достигло конечного пункта т.е. приложения, которому предназначалось.


O>Если надо действительно нормальное решение, которое работает почти везде,
O>советую смотреть на TDI/LSP/WFP. Иных вариантов попросту не существует.

Глупы вопрос, но LSP — это разве не Winsock 2.0 ?

Здравствуйте, Аноним, Вы писали:

А>Это курсовой проект. Цель: фильтр почты. На проекте несколько человек. Моя задача перехватить сообщение и отправить на анализ (за анализ отвечает другогой человек). В результате он сообщает можно или нельзя чтобы оно достигло конечного пункта т.е. приложения, которому предназначалось.

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

Здесь отчетливо выделяются два основных компонента — редиректор соединений и прокси-сервер.

Редиректор.
Можно сделать разными способами, но если бы у меня был выбор, я бы,
не задумываясь, предпочел драйвер режима ядра, а именно — TDI-фильтр.
Там редирект делается элементарно, а единственный вопрос, требующий усилий — это
сохранение оригинального адреса, на который был выполнен коннект, и передача его
прокси-серверу. Ну еще у TDI есть пара-тройка грабелек, но они не сильно
сложно обходятся, достаточно воспользоваться поиском по данному форуму.

TDI до сих пор активно используется антивирусным ПО, несмотря на то, что
сама технология в MSDN помечена как deprecated. Также можно использовать LSP, но
лично у меня с этой технологией отношения не сложились — помучился с полгодика,
да в конце концов забросил, так ничего и не добившись. Если не требуется поддержка
Windows XP, можно посмотреть на Windows Filtering Platform (WFP). Ее использует
MS Security Essentials, если не ошибаюсь.

Прокси-сервер.
Это наиболее сложное место, гораздо сложнее перехвата и редиректа соединений.

Во-первых, нужно заставить его пропускать TCP-трафик в обоих направлениях, в
несколько потоков, асинхронно, и еще поддерживать логику размыкания/разрыва соединений.
Иначе сеть не будет работать правильно или вообще "повиснет".

Во-вторых, каждая TCP-сессия, попадающая "под прицел", должна дополнительно
обрабатываться соответствующим обработчиком протокола. Например, на 25 порт
вешаем SMTP-обработчик, на порт 110 — обработчик POP3. Эти обработчики должны уметь
разбирать ответы почтового сервера и вытаскивать из них сообщения для анализа.
Хорошо, если найдется что-то готовое, а самому писать долго придется, сверяясь
постоянно с RFC и выясняя, почему что-то работает не по стандарту.

В-третьих, анализ почтовых сообщений подразумевает откладывание их отдачи клиенту.
Чрезвычайно важная деталь. К примеру, прокси перехватил от клиента команду RETR
(POP3), и теперь ждет от почтового сервера соответствующего ответа с телом сообщения.
Когда начинает поступать ответ, прокси не сразу отдает его клиенту, а складывает в
свой внутренний буфер. Когда ответ заканчивается, выполняется анализ и сообщение
передается на клиент. Если, конечно, анализатор не запрещает. В противном случае
нужно что-то придумать. Можно разорвать соединение, хотя это будет грубо и
для пользователя непонятно. А можно подменить это сообщение на свое, вставив в
него текст вроде "Сообщение запрещено к просмотру". Простор для творчества есть.

С задержкой ответа связаны некоторые трудности.
Тот же MS Outlook не захочет долго ждать ответа и сам разорвет коннект.
Для фильтрации HTTP эта проблема имеет огромное значение, особенно когда по данному
протоколу скачивается многогиговый файл — тогда задержка отдачи выглядит для
пользователя так, будто закачка повисла. Хотя на самом деле файл качается, но
пока не браузером, а прокси-сервером. Вот только пользователь этого не видит.

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

А>LSP — это разве не Winsock 2.0 ?

Winsock — набор функций для работы с сетью на уровне транспортных протоколов.
Грубо говоря.

LSP (Layered Service Providers) — стек сетевых поставщиков, обрабатывающих эти
функции до того, как они попадут ниже, в сервисы ядра операционной системы.

Здравствуйте, Аноним.

Кстати, сейчас многие интернет-провайдеры из-за спама просто закрывают 25 порт (SMTP).
А почтовые клиенты работают с этим протоколом через другой порт, например, 587 (Gmail).
Это я к тому, что жесткой связи между портом и номером протокола нет.

Поэтому ко всему написанному нужно присовокупить задачу определения трафика,
идущего через TCP-соединение. А это тоже непростая задача.