День добрый, Мастера!

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

Вроде бы похожими задачами занимается прозрачный прокси. Так вот: можно ли средствами Delphi реализовать такой прозрачный прокси? Или это очень сложно? Но ведь редирект внешних коннектов в NAT каким-то образом так и работает.

> Нужно на шлюзе или на любом компе в сети получать трафик
> по определенному порту


Направленный от кого к кому ?

Ну я же писал ... От неких клиентов (внешних) к нашим серверам.

Вернее, даже не так ... Желательно иметь перехват всего трафика (и от клиента к серверу и обратно) по установленному коннекту. С целью его анализа и своевременной блокировки, если что.

Но при этом серверу должно казаться, что никакого перехвата нет и коннект идет непосредственно от внешнего клиента. Т.к. с локальными клиентами он некорректно работает (разрешает им чрезмерно много, а это не есть правильно, но не регулируется, к сожалению).

Я не знаю, кого ты там зовешь "внешними клиентами", "нашими серверами" и т.д., но трафик м.б. перехвачен только на узлах, лежащих на маршруте следования от источника к приемнику, включая узлы источника и приемника.

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

Если уж мне не удалось с двух попыток толково все объяснить, попытаюсь в третий раз. На пальцАх:

1. В локальной сети есть сервера обрабатывающие некоторую поступающую информацию большого объема.
2. Есть клиенты не из локальной сети (внешние), отсылающие на сервера эту информацию.
3. Иногда клиент начинает дурить и посылать совершеннейшую ахинею (несколько сот кило и более). Либо (теоретически возможно) некто извне захочет похулиганить и будет слать неправдоподобную информацию.
4. Вся поступающая информация на серверах проходит несколько этапов проверок, позволяющих практически 100% отсеять брак и подделки. Но вот незадача - эти проверки осуществляются только после принятия всей инфы до последнего байта (а трафик капает).
5. Кроме того, для клиентов из локальной сети критичность этих проверок существенно занижена, что може привести к нехорошим последствиям (опять-таки, теоретически).
6. Исправить систему фильтрации невозможно. Т.к. она даже не продукт изготовителя системы, а используется им по лицензии. Да это, как утверждают и невозможно, т.к. она комплексная и работает со всем объемом информации скопом, начиная от IP-адреса коннекта и аутентификации и заканчивая подписями.
7. Вместе с тем обнаружено, что с высокой степенью надежности можно обнаруживать и отсеивать часть сбойной информации (40-60%) уже только на основании анализа первых нескольких килобайт. Это может существенно сэкономить трафик и разгрузить каналы. Уже сейчас на несколько десятков мегабайт в день. Дальше - больше.
8. Для этого надо, чтобы вначале весь трафик поступал на некий фильтр, который работает просто сквозняком - пропускает его в обе стороны и анализирует. В случае чего просто тупо выдает код ошибки и разрывает коннект.
9. Для этого использовали перехватчик, написанный с помощью компонента TIdTCPServer. Поставили его на шлюзе. При коннекте внешнего клиента он создавал новое подключение к серверу и служил ретранслятором.
10. Все было бы замечательно. Но тут оказалось, что сервер принимающий информацию теперь воспринимает коннект не от удаленного клиента, а с IP шлюза. А в этом случае отключена проверка непротиворечивости данных. Т.е. может оказаться, что давление стало отрицательным, а температура носителя приближается к температуре плавления стали ... Это не страшно, но диспетчера начинают паниковать.
11. Система самопальной фильтрации получилась достаточно удобная и отказываться от нее как-то неохота. Поэтому встал вопрос о том, нельзя ли сделать ретрансляцию по принципу NAT, чтобы сохранять адреса внешних коннектов?

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

е-а.
Ты излагаешь беду отнюдь не устами человека, знающего сеть.
Подать сюда вашего админа !)

Запросы передаются достаточно быстро. Сотни килобайт - не трафик для быстрой сети. Пока обработаешь запрос, выдашь команду на блокировку на маршрутизатор - уже весь пакет принят будет.


> ретрансляцию по принципу NAT,


В твоём случае серыми адресами будут считаться как раз внешние, и, следовательно, все будут скрываться.

А попытаться дать серверу исходный адрес можно по принципу прозрачного прокси...

> А попытаться дать серверу исходный адрес можно по принципу
> прозрачного прокси...

С этого момента, пожалуйста, поподробнее. Можно ли средствами Delphi это реализовать? Если можно, то в какую сторону рыть?

По поводу приема пакетов. Дело в том, что весь блок информации разбит на подблоки где-то по 10-20Кб. И OPC-сервер запрашивает каждый подблок отдельно. Т.е. сначала опрашивается мастер-контроллер, потом по цепочке все подчиненные (или не все - в зависимости от настроек). Поэтому, если разорвать коннект сразу после опроса мастер-контроллера, то удастся отсечь где-то 95% заведомо недостоверной информации.

To Сергей М. ©:

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

> Pochemuk   (07.04.08 08:57) [8]


> из 3-х Ваших ответов мне не удалось почерпнуть ни капли
> полезной информации


Угу.
А и из того что ты изложил, надо понимать, можно почерпнуть море полезной инф-ции ?

Ты даже не соизволил конкретизировать ни структуру своей сети ни системное ПО, работающее на хосте-шлюзе.

> ... не соизволил конкретизировать ни структуру своей сети ни
> системное ПО, работающее на хосте-шлюзе.
Ибо не важно.
Но если это как-то поможет, то пожалуйста ...

Структура практически стандартная. Один домен под Win2KServer. Шлюз тоже Win2KServer. Обработка телеметрии под Win2K3Server. Там установлены OPC-сервера принимающие инфу с объектов. Т.е. Объект коннектится к шлюзу по предопределенному порту, тот NAT`ом перебрасывает коннект на диспетчерский сервак. OPC-сервер может работать как в режиме опроса (выступает клиентом), так и в режиме зондового приема (работает именно сервером). В последнем случае при перенаправлении NAT`ом адрес внешнего объекта не меняется. И OPC-сервер считает, что к нему приконнектился непосредственно внешний клиент. Если же делать перенаправление не NAT`ом, а самопальным нашим фильтром, то коннект воспринимается с локального IP шлюза или того компа, на котором еще этот фильтр может быть установлен (например на самом диспетчерском сервере). В этом случае в OPC жестко забито, что это может быть имитатор или просто считает, что надежность связи очень большая и очень придираться к цифрам не следует.

Никаких управляемых свичей и роутеров внутри локалки нет. Все на простых неуправляемых свитчиках.

На каком из упомянутых хостов работает "самопальный фильтр" ?

Что мешает использовать для перехвата трафика , например, WinPCap ?

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

Так там же на ассемблере, а не на Pascal. Даже не на C.

> там же на ассемблере, а не на Pascal. Даже не на C


Да хоть на тарабарском.
Ссылка приведена как вектор куда копать.

Да при чем здесь вектор?
Вектора я последний раз лет 15 назад менял. Как раз на ассемблере. Еще для DOS. Всякие извращения творил - то закапывал перехватчик аж в оригинальное системное прерывание, чтобы не отсвечивал, то наоборот делал всплывающим, дабы всегда самым первым получал управление. Но с тех пор я и без понятия, что это такое. И вообще, есть ли они в Виндах. Мне нужно попроще: Вот библиотека (.dll, компоненты, исходники), вот описание функций, вот рабочие примеры. А самому копать у меня нет ни времени, ни желания. Проще уж нанять специально обученных кулибиных.
А это идея! Возьму сейчас ящик пива, поеду в SMART-SOFT (это которые Traffic Inspector наваяли), посижу с Мишей Белиным, если его еще не уволили. Пусть меня сведет со своими голованами. Уж они должны знать. Может сторгуемся.
Ибо я понял, что стандартными средствами Delphi тут ничего не сделаешь с кондачка. А больше я ничего и не помню уже.

"Правильные" админы ставят на шлюз линух и не парятся - IPTables дает полный контроль над трафиком любого сетевого интерфейса.