информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Phrack #70/0x46 
 Возможно, Facebook наступил на... 
 50 лет электронной почте 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[upd]посмотрел на своей висте сп1 nestat -a -n -o 15.04.08 00:05  Число просмотров: 4271
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 15.04.08 01:50  Количество правок: 3
<"чистая" ссылка>
посмотрел на своей висте сп1 nestat -a -n -o
> 49152,
wininit.exe

> 49153,
непонятно. Держит svchost в котором пачка сервисов. Стопнул все кроме event log и dhcp - порт открыт. Убил svchost и перезапустил event log и dhp - порта никто не открыл ;-\

>49154,49155,
тоже есть

>49156,49157,49159,61215,62715,61214
а нету

зато есть 53380 и 53740, которые впрочем закрылись при стопании сервисов/драйверов методом научного тыка. Слегка погуглил - все очень темно. Вот нашел маленький прикол - http://www.eggheadcafe.com/software/aspnet/29259229/tcp-ports-6287964854-blo.aspx

Ладно, приатачился к одному из svchost'ов. Конкретно к тому который держит 49153. Понаставлял бряк и стал к нему телнетом коннектиться. В результате пришел к выводу что это имеет какое то отношение к RPC.
Итак сокет нарисовался так:
WS2_32!WSASocketW+0x2
RPCRT4!WS_SubmitAccept+0x43
RPCRT4!WS_NewConnection+0x13c
RPCRT4!COMMON_ProcessCalls+0x2b6
RPCRT4!LOADABLE_TRANSPORT::ProcessIOEvents+0x138
RPCRT4!ProcessIOEventsWrapper+0xd
RPCRT4!BaseCachedThreadRoutine+0x5c
RPCRT4!ThreadStartRoutine+0x1e
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x23
ntdll!_RtlUserThreadStart+0x1b

Аксептить микрософт не стал стандартным способом, а позвал mswsock!MSAFD_AcceptEx
Далее были такие вызовы:
762dfca4 e89683f7ff call RPCRT4!IsHTTPv1Protocol
762dfcb0 e8b44ffdff call RPCRT4!HttpSendIdentifyResponse
На что я просто не знал что сказать ему в телнете и закрыл нафиг. RPC закрыл сокет честно позвав closesocket.
Остальных не дебажил, спать охота. Есть предположение что какие то сервисы поднимают RPC сервера, и RPCRT4 открывает порты под них сразу. 135й порт - это ведь просто mapper, через который RPC договаривается куда будет идти подключение дальше для конкретного RPC подключения. RPC под вистой был переписан на корню, возможно теперь RPC все время сервера держат порты открытыми порты. А указанные процессы просто юзают RPC.
[upd]
Предположение подтвердилось экспериментом: убил svchost "содержащий" сервисы eventlog, audiosrv, dhcp и еще чета. svchost держал порт 49153. Ручками стартанул dhcp - svchost поднялся, в нем dhcp. портов не занимает. Потом стартанул eventlog - и новорожденный svchost открыл порт 49180. Т.е. это явно порты, поднимаемые RPC рантаймом. Причем из определенного пула >=49152, возможно для облегчения конфигурения файрволла.
<operating systems> Поиск 








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


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