Всем доброго времени суток!

У меня следующий вопрос: если установить чистую Win7, то можно видеть следующие открытые порты:
TCP 135 LISTENING svchost.exe
TCP 139 LISTENING system
TCP 445 LISTENING system
TCP 49152 LISTENING wininit.exe
TCP 49153 LISTENING svchost.exe
TCP 49154 LISTENING svchost.exe
TCP 49155 LISTENING services.exe
TCP 49156 LISTENING lsass.exe

вопрос в том, как узнать по каким протоколам (уровня выше транспортного) могут принимать пакеты эти порты?
Первое, что приходит в голову — установить на виртуалку какую-либо ОС (например XP) или сесть за другую машину в той же сети, запустить на ней сниффер (например Wireshark) и попытаться пообщаться между машинами. Под общением понимается — зайти в расшаренные папки первой машины (где Win7), т.е. просмотр, переименование, копирование, перемещение, запуск файлов. Далее можно в Wireshark посмотреть, какие протоколы были задействованы (было выявлено только 3 протокола — Lanman, по которому даже RFC нет, NetBIOS и SMB2). Но проблема в том, какие еще действия можно выполнить, для того, чтобы расширить этот список протоколов? Что еще кроме просмотра, копирования и т.д. файлов можно сделать?

И второй вопрос: для чего нужны динамические порты 49152-49156? Зачем, например, процессу для служб Windows — svchost.exe его использовать? При том, что он к нему уже привязан 135 порт?

Спасибо.

P.S. Google излазан вдоль и поперек...

Процесс svchost часто не один, разные процессы хостят разные сервисы. По dll подгруженным в процесс svchost можно пытаться понять какие именно сервисы хостит конкретный процесс и предположить, зачем он наоткрывал эти порты.

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

D_K>вопрос в том, как узнать по каким протоколам (уровня выше транспортного) могут принимать пакеты эти порты?

Только эвристическими методами, а еще заглядыванием в IANA — http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
Хотя номера портов закрепляются за определенными протоколами (80 — HTTP, 20/21 — FTP, и так далее),
жесткое соответствие может быть нарушено. Через тот же 80 порт запросто может пойти что-то другое, нежели HTTP.

D_K>И второй вопрос: для чего нужны динамические порты 49152-49156?

Динамические порты — это иногда очень удобно.
Например, у меня есть программа, которая принимает команды по TCP и выполняет некие действия.
Вместо того, чтобы привязывать ее к определенному порту, "зашивая" ее номер внутри программы, я
позволяю операционной системе назначить для этого любой незанятый порт. Вдобавок получаю гарантию
того, что данный порт свободен и не используется другой программой.

D_K>Зачем, например, процессу для служб Windows — svchost.exe его использовать? При том, что он к нему уже привязан 135 порт?

TCP/UDP используются не только для веб-технологий.
Иногда это единственный разумный вариант для какой-то задачи обеспечения коммуникаций внутри
одной машины. Так что ситуация, когда одна программа забирает себе два и более портов, вполне нормальна.

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

D_K>Всем доброго времени суток!

D_K>У меня следующий вопрос: если установить чистую Win7, то можно видеть следующие открытые порты:
D_K> TCP 135 LISTENING svchost.exe
D_K> TCP 139 LISTENING system
D_K> TCP 445 LISTENING system
D_K> TCP 49152 LISTENING wininit.exe
D_K> TCP 49153 LISTENING svchost.exe
D_K> TCP 49154 LISTENING svchost.exe
D_K> TCP 49155 LISTENING services.exe
D_K> TCP 49156 LISTENING lsass.exe

D_K>вопрос в том, как узнать по каким протоколам (уровня выше транспортного) могут принимать пакеты эти порты?
Ну как бы номера портов известные — по ним и узнать...

D_K>И второй вопрос: для чего нужны динамические порты 49152-49156? Зачем, например, процессу для служб Windows — svchost.exe его использовать?
svchost — это процесс, в котором живет много сервисов. Какой-то сервис использует порт 135, какой-то 49152 — тут ничего загадочного.

Сами порты 49xxx — это слушающие RPC интерфейсы, которые используют транспорт TCP. Если интересно, что это конкретно за RCP — найди аналог rpcdump под семерку (из Resource Kit'а для 2003-й не подошел на моей семерке).

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

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

O>Динамические порты — это иногда очень удобно.
O>Например, у меня есть программа, которая принимает команды по TCP и выполняет некие действия.
Идея понятна, однако каков смысл заранее иметь список открытых портов для будущего использования стороннего ПО(если я правильно вас понял)? Ведь это лишний шанс для проведения сетевой атаки.
Т.е. в чем выгода? В том, что мы экономим время для выделения уже готового открытого порта для своей программы? Мне кажется — это не очень накладно...

O>Вместо того, чтобы привязывать ее к определенному порту, "зашивая" ее номер внутри программы, я
O>позволяю операционной системе назначить для этого любой незанятый порт. Вдобавок получаю гарантию
O>того, что данный порт свободен и не используется другой программой.
В тоже время к этим портам (49152-49156) уже привязаны конкретные процессы, и если ОС захочет выделить их другим процессам (нашей программе), она просто переназначит их? Не потребуется ли на это больше времени, чем выделение нового порта? Еще раз, если я правильно понял.

И основной вопрос остался — что еще можно выполнить, какие еще действия можно произвести для того, чтобы сымитировать более полное сетевое общение между машинами?

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

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

DOO>Ну как бы номера портов известные — по ним и узнать...
Это не всегда так, к сожалению, в инфе IANA ничего не сказано про SMB в графе 139 порт, в этом-то вся и проблема...

DOO>svchost — это процесс, в котором живет много сервисов. Какой-то сервис использует порт 135, какой-то 49152 — тут ничего загадочного.
Загадка в том, точнее вопрос скорей, что этот порт 49152 — динамический, и IANA не регистрирует по такие порты конкретные службы — зачем его выделили в Vista и 7, в XP все прекрасно работало...

DOO>Сами порты 49xxx — это слушающие RPC интерфейсы, которые используют транспорт TCP. Если интересно, что это конкретно за RCP — найди аналог rpcdump под семерку (из Resource Kit'а для 2003-й не подошел на моей семерке).
Ясно.

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


DOO>>Ну как бы номера портов известные — по ним и узнать...
D_K>Это не всегда так, к сожалению, в инфе IANA ничего не сказано про SMB в графе 139 порт, в этом-то вся и проблема...
Отсутствие в базах IANA еще не значит, что порт не well-known


D_K>Загадка в том, точнее вопрос скорей, что этот порт 49152 — динамический, и IANA не регистрирует по такие порты конкретные службы — зачем его выделили в Vista и 7, в XP все прекрасно работало...
Ну в XP он был бы с другим номером, для начала: http://support.microsoft.com/kb/929851
А может даже использовал другой транспорт (RCP еще, например, именованные каналы активно юзает — а они все по SMB идут).

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

DOO>Ну в XP он был бы с другим номером, для начала: http://support.microsoft.com/kb/929851
Честно сказать, не понятна фраза — "Майкрософт повысила диапазон портов динамического клиента для исходящих подключений в Windows Vista и Windows Server 2008. Новый начальный порт по умолчанию — 49152 и конечный порт по умолчанию — 65535. В этом заключается отличие от параметра, более ранних версий Windows, в которых используется диапазон портов по умолчанию 1025-5000". Ведь согласно IANA с 0-1024 общеизвестные порты, с 1025-49151 зарегистрированные, и далее динамические. Т.е. до Vista в Windows динамическими портами были и зарегистрированные (1025-5000)?

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


D_K>Честно сказать, не понятна фраза — "Майкрософт повысила диапазон портов динамического клиента для исходящих подключений в Windows Vista и Windows Server 2008. Новый начальный порт по умолчанию — 49152 и конечный порт по умолчанию — 65535. В этом заключается отличие от параметра, более ранних версий Windows, в которых используется диапазон портов по умолчанию 1025-5000". Ведь согласно IANA с 0-1024 общеизвестные порты, с 1025-49151 зарегистрированные, и далее динамические. Т.е. до Vista в Windows динамическими портами были и зарегистрированные (1025-5000)?
Ну да. Страшного-то ничего особо не было... Нас вот еще когда сетям учили, тогда говорилось, что только первые 1024 зарезервированы — время-то идет

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

D_K>Идея понятна, однако каков смысл заранее иметь список открытых портов для будущего использования стороннего ПО(если я правильно вас понял)? Ведь это лишний шанс для проведения сетевой атаки.
D_K>Т.е. в чем выгода? В том, что мы экономим время для выделения уже готового открытого порта для своей программы? Мне кажется — это не очень накладно...

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

А выгоды — они в гибкости, чтобы не связывать свою программу с определенным номером порта,
потому что так есть риск возникновения конфликта с другим ПО.

D_K>В тоже время к этим портам (49152-49156) уже привязаны конкретные процессы, и если ОС захочет выделить их другим процессам (нашей программе), она просто переназначит их? Не потребуется ли на это больше времени, чем выделение нового порта? Еще раз, если я правильно понял.

ОС не переназначит порты.
Если какое-то приложение попробует использовать уже занятый порт, оно получит ошибку и все.
Вам, наверное, лучше почитать какую-то литературу по этим вопросам, там обычно
такие вещи расписываются от и до.

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

O>Никаких заранее открытых портов и предварительно выделенных ресурсов нет...
Okman, спасибо за развернутый ответ, однако мне кажется мы немного говорим о разных вещах: для чего нужны динамические порты — абсолютно ясно, вы все правильно и верно описали, но мой вопрос состоял в том, зачем в Vista и Win7 после установки уже прослушиваются порты 49152-49156 из динамического диапазона? Для чего они нужны? Если в них нуждается какая-то служба ОС, так у IANA наверно уже зарегистрирован под нее отдельный порт из диапазона 0-1024... Если не зарегистрирован, ну тогда можно еще понять... А что тогда это за служба? Были в XP 135, 139, 445 — всегда одни и те же, их роль ясна и понятна, тут устанавливаю Win7 и вот тебе еще 5 каких-то портов из динам. диапазона, на кой черт они нужны...

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

DOO>Ну да. Страшного-то ничего особо не было... Нас вот еще когда сетям учили, тогда говорилось, что только первые 1024 зарезервированы — время-то идет
Все ясно.

А насчет второго вопроса — "что еще можно выполнить, какие еще действия можно произвести для того, чтобы сымитировать более полное сетевое общение между машинами?", нет никаких мыслей?

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

D_K>А насчет второго вопроса — "что еще можно выполнить, какие еще действия можно произвести для того, чтобы сымитировать более полное сетевое общение между машинами?", нет никаких мыслей?
А. Пропустил.
В семерку встроена утилита rpcping (раньше тоже в resource kit'ах шла). Соответственно, она позволит более информативно пообщаться с портами RPC интерфейсов. Есть еще более убойный rpcclient из Samba suite.
Для общение с текстовыми протоколами подойдет telnet. Если протокол обернут в SSL — ssl-telnet (есть в любом линуксе).
На вскидку больше не подскажу адекватных средств...

D_K>У меня следующий вопрос: если установить чистую Win7, то можно видеть следующие открытые порты:
D_K> TCP 135 LISTENING svchost.exe
rpc port mapper

D_K> TCP 139 LISTENING system
netbios

D_K> TCP 445 LISTENING system
SMB

D_K> TCP 49152 LISTENING wininit.exe
D_K> TCP 49153 LISTENING svchost.exe
D_K> TCP 49154 LISTENING svchost.exe
D_K> TCP 49155 LISTENING services.exe
D_K> TCP 49156 LISTENING lsass.exe
а это RPC серверы развесили свои интерфейсы на динамически распределенные (тем самым маппером в сервисе rpc) порты

D_K>И второй вопрос: для чего нужны динамические порты 49152-49156? Зачем, например, процессу для служб Windows — svchost.exe его использовать? При том, что он к нему уже привязан 135 порт?
135й порт — это портмаппер, по сути мультиплексор, используемый для того чтобы по GUID RPC интерфейса определить на каком именно порту данной машины реально висит сервер. Когда в конекста какого-либо процесса ктото регистрирует RPC интерфейс с определенным GUID, указывая, что к нему мона подключатся по tcp/ip (ncacn_ip_tcp) rpcrt4.dll посылает запрос (по LPC) в port mapper локального RPC сервиса, тот находит ей свободный порт (любой вообще-то, жесткой привязки нету), связывается с файрволлом, разрешает этот порт, запоминает в своей мапе GUID->порт и возвращает его номер процессу, который хочет поднять RPC сервер на тот GUID. RPCRT4.dll в том процессе биндится на этот порт и обслуживает подключения к нему.
В дальнейшем, когда кто-то из интер/интра-нетов хочет подключиться к RPC серверу с таким же GUID на этом компе он вначале конектицца на 135й порт, говорит — а скажи ка мне, на каком порту у тебя крутицца такой то сервер RPC интерфейса с таким то GUID, маппер на 135м порту висящий смотри в своей мапе, возвращает порт клиенту, клиент потом конектицца на тот порт и далее общаецца с ним по внутреннему протоколу RPC.

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

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

DOO>>Ну в XP он был бы с другим номером, для начала: http://support.microsoft.com/kb/929851
D_K>Честно сказать, не понятна фраза — "Майкрософт повысила диапазон портов динамического клиента для исходящих подключений в Windows Vista и Windows Server 2008. Новый начальный порт по умолчанию — 49152 и конечный порт по умолчанию — 65535. В этом заключается отличие от параметра, более ранних версий Windows, в которых используется диапазон портов по умолчанию 1025-5000". Ведь согласно IANA с 0-1024 общеизвестные порты, с 1025-49151 зарегистрированные, и далее динамические. Т.е. до Vista в Windows динамическими портами были и зарегистрированные (1025-5000)?

До Vista в Windows плевали с высокой колокольни на эту рекомендацию IANA, как сейчас вообще много где плюют (например, в Linux по умолчанию динамический диапазон 32768-61000, вообще непонятно, из каких принципов он такой). Важно отделить порты ниже 1024 и не давать к ним допуск без административных прав, даже если свободны, а качество соблюдения зоны свободного распределения — не настолько важный фактор.

Но корректность диапазона свободного распределения может быть важной, например, для работы NAT, средств IDS в потоке трафика и т.д., когда нет воспоминаний о полном состоянии TCP сессий в потоке, но есть правило типа "если порт с одной стороны >= 49152, добавляем баллы за то, что именно они инициировали соединение".

Спасибо за ответ. Стало более понятно. Не подскажешь литературу по этой теме?

O>а это RPC серверы развесили свои интерфейсы на динамически распределенные (тем самым маппером в сервисе rpc) порты

А какое значение имеет количество этих портов? В XP был все лишь один (1028), в Vista и Win7 их пять. Это ведь сделано намеренно. С какой целью?

O>>а это RPC серверы развесили свои интерфейсы на динамически распределенные (тем самым маппером в сервисе rpc) порты
D_K>А какое значение имеет количество этих портов? В XP был все лишь один (1028), в Vista и Win7 их пять. Это ведь сделано намеренно. С какой целью?
Портов будет столько, сколько различных процессов в системе в которых крутяцца серверы RPC интерфейсов допускающих подключение по tcp/ip.
Насчет XP не уверен так ли оно работает оно там (не дебажил RPC/ncacn_ip_tcp) в ней. Но может там просто меньше таких сервисов, которые по RPC/ncacn_ip_tcp принимаю удаленных клиентов.

Ясно. Спасибо.

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

O>а это RPC серверы развесили свои интерфейсы на динамически распределенные (тем самым маппером в сервисе rpc) порты

А откуда информация, что это именно RPC серверы? Как это можно узнать?

Во первых — порты 49152-49156 НЕ ЗАРЕЗЕРВИРОВАНЫ под RPC. Просто в семерке динамический диапазон портов распределяются примерно начиная с 49152, в чем несложно убедиться написав:

WSADATA wd = {0};
WSAStartup(257, &wd);
int sc = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
sockaddr_in sin = {AF_INET, 0};
bind(sc, (sockaddr *)&sin, sizeof(sin));
int nl = sizeof(sin);
getsockname(sc, (sockaddr *)&sin, &nl);
printf("Port=%u\n", ntohs(sin.sin_port));

RPCRT4.dll делает примерно тоже самое когда поднимает слушающий сокет для интерфейсов регистрируемых текущим процессом. Узнал я это при помощи дебаггера. Доводилось дебажить кишки rpcrt4.dll и стандартных виндовых сервисов. Вот к примеру как появляется открытый порт в одном из svchost'ов:

0:011> kv fffff
Memory ChildEBP RetAddr Args to Child
00c5f4d8 75a53477 00000840 00000014 01c30c10 ws2_32!listen (FPO: [2,1,0])
34 00c5f50c 75a531bc 00000001 01c30848 01c30848 rpcrt4!WS_ServerListenCommon+0x258
8c 00c5f598 75a52dfa 01c30a78 00000000 00c5f630 rpcrt4!TCP_ServerListenEx+0x364
28 00c5f5c0 75a5396e 01c30a78 00000000 00c5f630 rpcrt4!TCP_ServerListen+0x21
28 00c5f5e8 75a72854 00000000 00c5f630 0000000a rpcrt4!OSF_ADDRESS::ServerSetupAddress+0x2a
78 00c5f660 75a56f4d 00000000 714299ac 0000000a rpcrt4!RPC_SERVER::UseRpcProtocolSequence+0x653
3c 00c5f69c 75a56fe0 00000000 714299ac 0000000a rpcrt4!I_RpcServerUseProtseq2W+0x61
1c 00c5f6b8 75a57032 714299ac 0000000a 00000000 rpcrt4!RpcServerUseProtseqExW+0x18
24 00c5f6dc 714298bf 714299ac 0000000a 00000000 rpcrt4!RpcServerUseProtseqW+0x4f
48 00c5f724 71429849 00000000 00000000 714297db schedsvc!RpcServer::StartServer+0x70 (FPO: [0,9,4])
c 00c5f730 714297db 4d85c3ec 00000001 00c5f7d0 schedsvc!RpcServer::StartRpcServer+0x10 (FPO: [0,0,0])
48 00c5f778 71428405 00000001 0019dba8 00179910 schedsvc!JobsService::Initialize+0x41b (FPO: [2,12,4])
1c 00c5f794 71428338 7142835c 00000001 0019dba8 schedsvc!CNtService::Run+0x99 (FPO: [4,0,4])
cc 00c5f860 00541499 00000001 0019dba8 00000000 schedsvc!ServiceMain+0x40 (FPO: [2,41,4])
2c 00c5f88c 76de75a8 00000001 0019dba8 00000000 svchost!ServiceStarter+0x17a (FPO: [2,5,0])
14 00c5f8a0 75e11174 0019db98 00c5f8ec 7734b3f5 sechost!ScSvcctrlThreadA+0x21 (FPO: [1,0,4])
c 00c5f8ac 7734b3f5 0019db98 77c9903f 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
40 00c5f8ec 7734b3c8 76de7587 0019db98 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [SEH])
18 00c5f904 00000000 76de7587 0019db98 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

0:011> du 714299ac
714299ac "ncacn_ip_tcp"

Спасибо за ответ. Теперь ясно, где искать.
Но появился один вопрос: в описании параметра ncacn_ip_tcp (так же как и для остальных) на msdn сказано, что Client only: MS-DOS, Windows 3.xClient and Server: Windows Server 2003, Windows XP, Windows 2000, Windows NT. Значит ли это, что цель использования endpoint с таким атрибутом ncacn_ip_tcp — это совместимость с предыдущими версиями ОС? Ну раз в этом списке нет ни Vista, ни Windows 7, ни Server 2008...

D_K>Но появился один вопрос: в описании параметра ncacn_ip_tcp (так же как и для остальных) на msdn сказано, что Client only: MS-DOS, Windows 3.xClient and Server: Windows Server 2003, Windows XP, Windows 2000, Windows NT. Значит ли это, что цель использования endpoint с таким атрибутом ncacn_ip_tcp — это совместимость с предыдущими версиями ОС? Ну раз в этом списке нет ни Vista, ни Windows 7, ни Server 2008...
Скорее всего просто забыли проапдейтить док. Кстати где вы это нашли? Тут ниче такого не написано

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

O> Кстати где вы это нашли? Тут ниче такого не написано

А вот тут рядом, в Protocol Sequence Constants.

O>Скорее всего просто забыли проапдейтить док.

Возможно, однако на этой странице указано — Build date: 9/7/2011.

O>>Скорее всего просто забыли проапдейтить док.
D_K>Возможно, однако на этой странице указано — Build date: 9/7/2011.
Написал им коммент, пусть правят, если не проигнорят. Build date это все таки не Last edited/updated date

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

O>Написал им коммент, пусть правят, если не проигнорят. Build date это все таки не Last edited/updated date

Согласен, но все же...

И, ononim, последний вопрос: нигде не могу найти информацию про то, что такое endpoint в общем смысле (ну или хотя бы в контексте RPC), что эта "точка" из себя представляет и для чего она нужна, какую она может дать информацию?
На msdn единственная статья Endpoint attribute, и то короткая. Если можно, просто ссылку, где это можно найти, прочитать...

Спасибо.

Например, утилита rpcdump из Resource Kit'a дает следующую информацию:
Querying Endpoint Mapper Database...
116 registered endpoints found.
ProtSeq:ncacn_np
Endpoint:\PIPE\InitShutdown
NetOpt:
Annotation:
IsListening:NOT_PINGED
StringBinding:ncacn_np:WIN-PM4PHQODVT8[\\PIPE\\InitShutdown]
UUID:d95afe70-a6d5-4259-822e-2c84da1ddb0d
ComTimeOutValue:RPC_C_BINDING_MIN_TIMEOUT
VersMajor 1 VersMinor 0

и т.д..

Значит ли это, что я, находясь на удаленной машине, могу достучаться до именованного канала InitShutdown той машины, у которой эта "точка" зарегистрирована, по протоколу ncacn_np, т.е. NetBIOS?

D_K>И, ononim, последний вопрос: нигде не могу найти информацию про то, что такое endpoint в общем смысле (ну или хотя бы в контексте RPC), что эта "точка" из себя представляет и для чего она нужна, какую она может дать информацию?
D_K>На msdn единственная статья Endpoint attribute, и то короткая. Если можно, просто ссылку, где это можно найти, прочитать...

нуу.. Читайте что такое RPC. Грубо говоря это системный механизм позволяющий из одного процесса дергать интерфейсы которые реализованы в другом процессе (опционально — еще и на другом компе). Пол-винды через эту хрень работает. Out-of-process COM сервера в частности.

D_K>Значит ли это, что я, находясь на удаленной машине, могу достучаться до именованного канала InitShutdown той машины, у которой эта "точка" зарегистрирована, по протоколу ncacn_np, т.е. NetBIOS?
А то. Как думаете работает shutdown.exe с ключиком -m ?

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

O>А то. Как думаете работает shutdown.exe с ключиком -m ?

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

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

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

O>>А то. Как думаете работает shutdown.exe с ключиком -m ?
D_K>Согласен. Но здесь препятствием, наверно, будет дескриптор защиты, запрещающий несанкционированный доступ к каналу. Разве нет?
Не совсем, подключиться к пайпу (или к сокету в случае tcp/ip endpoint'а) могут все. Но у RPC сам проверяет клиента подключившегося (в случае пайпа — используется механизм авторизации пайпов, в случае tcp/ip — RPC сам проводит авторизацию, вернее юзает стандартные методы авторизации которые установлены в винде. В случае шатдауна надо авторизоваться к тому компу от имени юзера которому 1) позволено подключаться удаленно 2) позволено выключать комп. Все это настраивается через secpol.msc и gpedit.msc

Понятно. Спасибо.