информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
была такая штука 12.11.09 16:29  Число просмотров: 2358
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
hummingbird socksifier

ставится на систему и потом задаёшь ей фильтрами какой трафик заворачивать в socks
Правда последний раз я её использовал в 2003

коля
<networking>
Существуют ли in-process соксификаторы? 09.11.09 10:40  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 09.11.09 10:45  Количество правок: 3
<"чистая" ссылка>
Программа работает с M$ SQL сервером через ADO.
Объекты ADO-подключений, насколько я знаю, не умеют работать через SOCKS-прокси.
Задача: заставить.
Насколько я знаю, есть внешние программы-"соксификаторы", которые прозрачно для процесса обволакивают его вызовы к винсоксу, и программа думает, что TCP соединения она делает как обычно, а на самом деле всё идёт через прокси.
Нужно сделать это для конкретной программы изнутри.
Как я это вижу в идеале: подключаю "соксифицирующую" dll, дёргаю из неё функцию "socksify" с параметрами нужного SOCKS-прокси, и после этого ВСЕ TCP-соединения, которые откроет программа, будут идти через SOCKS-прокси.
Заранее всем спасибо за советы
была такая штука 12.11.09 16:29  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
hummingbird socksifier

ставится на систему и потом задаёшь ей фильтрами какой трафик заворачивать в socks
Правда последний раз я её использовал в 2003

коля
Да их море -- FreeCap, WideCap и проч... 12.11.09 16:51  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Интересует же вариант, чтобы ничего в систему не ставя, получить нужный эффект, программа сама "просит" об этом скажем некую dll.
Та же FreeCap использует технологию внедрения DLL в процесс...
А тут ничего внедрять не надо, прога сама говорит: "Ну пожалуйста..." ;)

У фрикапа доступны исходники, ща ковыряем их, скорее всего, подойдёт.
Не имеет значения, в каком виде представлен драйвер, будь то... 09.11.09 19:53  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> Программа работает с M$ SQL сервером через ADO.
> Объекты ADO-подключений, насколько я знаю, не умеют
> работать через SOCKS-прокси.

Не имеет значения, в каком виде представлен драйвер, будь то ADO/OLEDB или ODBC. За некоторым исключением, все они лезут на SQL сервер, порт TCP 1344.

> Задача: заставить.
> Насколько я знаю, есть внешние программы-"соксификаторы",
> которые прозрачно для процесса обволакивают его вызовы к
> винсоксу, и программа думает, что TCP соединения она делает
> как обычно, а на самом деле всё идёт через прокси.
> Нужно сделать это для конкретной программы изнутри.
> Как я это вижу в идеале: подключаю "соксифицирующую" dll,
> дёргаю из неё функцию "socksify" с параметрами нужного
> SOCKS-прокси, и после этого ВСЕ TCP-соединения, которые
> откроет программа, будут идти через SOCKS-прокси.
> Заранее всем спасибо за советы

Зачем заставлять драйверы работать через socks прокси, если подобная технология прекрасно может работать через NAT или мапинг порта?
Потому что есть конторы, где нету NAT, но есть SOCKs. 09.11.09 20:46  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 09.11.09 21:05  Количество правок: 3
<"чистая" ссылка>
> Не имеет значения, в каком виде представлен драйвер, будь
> то ADO/OLEDB или ODBC. За некоторым исключением, все они
> лезут на SQL сервер, порт TCP 1344.
Полезут они на тот порт, какой скажешь в строке подключения, по умолчанию он 1433, M$ TDS протокол. Но это всё не важно. Важно то, что созданием TCP соединения я не занимаюсь, а занимается библиотека M$, и ничего с этим не поделать.

> Зачем заставлять драйверы работать через socks прокси, если
> подобная технология прекрасно может работать через NAT или
> мапинг порта?
Потому что сабж. Поставят старый юзергейт и радуются -))
А если бы была возможность использования SOCKS в программе -- было бы фичастее.
Ну да, с "1344" я очепятался - запамятовал. 09.11.09 21:30  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> Полезут они на тот порт, какой скажешь в строке
> подключения, по умолчанию он 1433, M$ TDS протокол. Но это
> всё не важно. Важно то, что созданием TCP соединения я не
> занимаюсь, а занимается библиотека M$, и ничего с этим не
> поделать.

Ну да, с "1344" я очепятался - запамятовал.

> > Зачем заставлять драйверы работать через socks прокси,
> если
> > подобная технология прекрасно может работать через NAT
> или
> > мапинг порта?
> Потому что сабж. Поставят старый юзергейт и радуются -))
> А если бы была возможность использования SOCKS в программе
> -- было бы фичастее.

Хы-хы. Недавно на amicon.ru терли похожую тему... Там проблема с подключением VPN клиента по UDP:87
Древний юзергейт, обычно, ставят на 32-битную XP. Так что же мешает поднять дополнительно Windows NAT? Еще было предложено использовать связку Windows NAT и форточные порты squid и wipfw. При использовании только старого юзергейта (v2.8), можно использовать мапинг порта TCP:1433
У них используются пароли на проксятине, если включить стандартный вендовозный NAT -- тырнет откроется для всех, кто вкурит нужный "шлюз по умолчанию". 09.11.09 21:46  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 09.11.09 21:48  Количество правок: 1
<"чистая" ссылка>
Про маппинг порта можно поподробнее? Смогут ли с его использованием несколько человек с разных машин одновременно ломиться на сервер?
В Керио винроуте -- да. Сомневаюсь, что в Юзергейте иначе. 09.11.09 22:48  
Автор: Lurga Статус: Elderman
<"чистая" ссылка>
Млин! Че вы гоните? ) 10.11.09 04:33  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 10.11.09 12:44  Количество правок: 3
<"чистая" ссылка>
Во-первых, с помощью wipfw, возможность NAT можно открыть только для некоторых узлов-отправителей и узлов/портов-получателей.

Во-вторых, не слишком хорошо знаком с Entensys UserGate, но в современном исполнении, этот продукт немногим отличается от современного Kerio Winroute Firewall. Эти два продукта очень похожи... Оба продукта умеют проводить авторизацию пользователя как в локальной базе пользователей и групп, так и в домене Windows NT+ (в т.ч. AD) и предоставляют практически идентичные возможности, но Entensys UserGate сильно переигрывает KWF по цене.
Мы чо? Мы ничо... 10.11.09 16:19  
Автор: Lurga Статус: Elderman
<"чистая" ссылка>
> Во-вторых, не слишком хорошо знаком с Entensys UserGate, но
> в современном исполнении, этот продукт немногим отличается
> от современного Kerio Winroute Firewall. Эти два продукта
> очень похожи... Оба продукта умеют проводить авторизацию
> пользователя как в локальной базе пользователей и групп,
> так и в домене Windows NT+ (в т.ч. AD) и предоставляют
> практически идентичные возможности, но Entensys UserGate
> сильно переигрывает KWF по цене.

Я просто в своё время довольно плотно работал с Керио винроут, а Юзергейт видел пару раз, так что по его поводу ничего путного сказать не могу.Что он догнал винроут по возможностям -- совершенно логично, зачем бы он иначе был нужен? :))
Я воще гнать не хотел, от корневого топика мы сильно отдалились ;) 10.11.09 11:22  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach