информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле ЛевинаЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Прикрыто это у меня..... Мне по-существу интересно.;((( 17.08.04 01:13  Число просмотров: 1350
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> а вообще - don't trouble trouble until trouble troubles you
> (~c)
> 135..139 это первым делом, и tcp, и udp.
> имхо, разумеется.

Прикрыто это у меня..... Мне по-существу интересно.;(((
Разве это запрещено спрашивать в форуме.

> а не нужно RPC в нет выставлять. совсем нет такой
> необходимости. (кто хочет спорить - слушаю внимательно).
> все что нужно, как уже было сказано, через тот же VPN
> делается - волосы остаются шелковисты.

Всё это прикрыто. И даже необходимости нет в RPC в инете.
<sysadmin>
Ламерский вопрос про 135 порт TCP 13.08.04 02:02  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Хочется узнать ваше мнение про RPC в имплементации виндоз. Вернее про опасность "открытия" этого порта в интернет.
Часто приходится слышать мнение, что мол, по 135-порту сейчас хакают направо и налево. Мол, что многие "червяки" проникают через этот порт. Приходится обсуждать эти вопросы с админами, и, поскольку я по натуре не админ, то часто не могу найти аргументов для того, чтобы отстоять свою точку зрения.

Моя точка зрения очень проста - для того, что бы вызвать удалённо по RPC процедуру, необходимо разрешить на межсетевом экране порты для тех соединений, что будут использоваться для маршалинга после того, как сервис epmap (TCP 135) позволит клиенту и серверу договориться о портах вторичных соединений. Другими словами открытие порта 135 на межсетевом экране по существу опасно только тогда, когда практически ничего не защищено ACL, или когда используются упрощённые ACL, разрешающие клиентам инет соединяться с любыми портами > велкновн (ну и в обратном направлении, разумеется). Т.е. когда мы разрешаем любые порты, что будут динамически "назначаться" и использоватся сервисами, работающими по RPC.

Каково Ваше мнение, товарищи админы и безопасники?
Спасибо.
Мнение. 13.08.04 13:41  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Другими словами открытие порта 135 на
> межсетевом экране по существу опасно только тогда, когда
> практически ничего не защищено ACL, или когда используются
> упрощённые ACL, разрешающие клиентам инет соединяться с
> любыми портами > велкновн (ну и в обратном направлении,
> разумеется). Т.е. когда мы разрешаем любые порты, что будут
> динамически "назначаться" и использоватся сервисами,
> работающими по RPC.
>
> Каково Ваше мнение, товарищи админы и безопасники?
> Спасибо.

Открытие порта 135 опасно в любом случае, если на систему не установлена заплатка RPC/DCOM (см. Cumulative Update for Microsoft RPC/DCOM (828741)), легко можно нахвататься вирей.
Если требуется открыть этот порт не для всех, а только для клиентов организации, то, IMHO, лучше всего использовать VPN соединение. В этом случае клиент, имея ключ шифрования, может подключить по dial-up с любого места и ip адреса и использовать необходимый ему сервис даже находясь за NAT'ом. Можно также использовать вариации туннелинга с шифрованием.

Microsoft Security Bulletin MS04-012
Спасибо за мнение. Заплатки, конечно, это да. Это все знают... 14.08.04 01:50  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Открытие порта 135 опасно в любом случае, если на систему
> не установлена заплатка RPC/DCOM (см. Cumulative Update for
> Microsoft RPC/DCOM (828741)), легко можно нахвататься
> вирей.

Спасибо за мнение. Заплатки, конечно, это да. Это все знают и делают. .....
Но я ведь вопрос задавал, как мне казалось, по существу.... Смотри, 135 порт имеет отношение к RPC, и уж тем более к DCOM (который использзует RPC только в качестве протокола более низкого уровня), такое же, как я к балерине. Он используется для того, чтобы промапить порты по которым клиент будет обмениваться данными с удалённо вызванной процедурой RPC. Всё.
Имею ввиду то, что фактически данные (когда на удалённом хосте уже запущена RPC-процедура, а на клиенте создана прокси-заглушка и т.п.) никогда не передаются непосредственно от клиента на 135 серверный порт. Для передачи данных используются вторичные соединения. В этом легко убедиться если промониторть трафик клиент-сервер. Там ты увидишь, что на стороне сервера RPC будут динамически открыты порты, например, 1026, 6000 - ..... и т.д.

Так вот, мой поинт был в том, что если в ACL ты разрешишь только 135 порт, а всё остальное задропишь (имеется ввиду трафик по динамическим портам, что использовал бы RPC на хосте жертвы), то RPCпросто будет не функционально. Ну не сможет атакер в этом случае обмениваться ни с чем на хосте жертвы. Трафик будет перекрыт ACL..... Извини, что говорю с таким апломбом в отношении работоспособности RPC + DCOM за межсетевым экраном. Это уже просто пробовано-перепробовано тыщу раз....

!!!!
А вот в отношении багов и возможноти хакнуть сам 135 порт (всего лишь epmap!!!) в имплементации виндовз, о возможности передачи данных с клиента на 135 порт, да так, чтоб передать туда каким-то образом виря - я и хотел бы узнать в форуме.


> Если требуется открыть этот порт не для всех, а только для
> клиентов организации, то, IMHO, лучше всего использовать
> VPN соединение. В этом случае клиент, имея ключ шифрования,
> может подключить по dial-up с любого места и ip адреса и
> использовать необходимый ему сервис даже находясь за
> NAT'ом. Можно также использовать вариации туннелинга с
> шифрованием.

Ещё раз спасибо за мнение. Но вопрос не стоял так - как сделать работу по RPC безопасной. Меня интересовало другое. То, что выше.
Извини, но не совсем понятно, чего конкретно ты хочешь. 14.08.04 18:05  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Ну да, без разрешения соединений на динамически распределяемые порты RPC сервера открытие порта 135 не имеет никакого смысла.

> !!!!
> А вот в отношении багов и возможноти хакнуть сам 135 порт
> (всего лишь epmap!!!) в имплементации виндовз, о
> возможности передачи данных с клиента на 135 порт, да так,
> чтоб передать туда каким-то образом виря - я и хотел бы
> узнать в форуме.

Нет надежных систем и всегда присутствует вероятность, что blackhat'ы найдут дыру в какой-либо службе на открытом порту и воспользуются ею раньше, чем производитель ПО узнает об уязвимости и выпустит заплатку. Совсем не обязательно, что дырявой системой в подобном случае окажется M$ ПО, это может оказаться и Unix, и Linux, и даже IOS Циски.
Опасность открытия 135 порта в инет на M$ ОС такая же, как опасность открытия портов 139 и 445(Microsoft-DS).
Как говориться: "Волков бояться - в лес не ходить".
Вот это я и хотел услышать от профессионалов. 15.08.04 02:17  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Ну да, без разрешения соединений на динамически
> распределяемые порты RPC сервера открытие порта 135 не
> имеет никакого смысла.
>

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

> Опасность открытия 135 порта в инет на M$ ОС такая же, как
> опасность открытия портов 139 и 445(Microsoft-DS).

Да почему ж в точности такая же? В точности такой же опасности, думаю, не может быть, ибо механизмы взлова, наверное, другие. Кроме того, для разных служб - разные средства обнаружения попыток интружн. Про 135 порт (если нет соответствующей IDS) тебе никто не скажет о попытках внедрения, если ты его открыл в инете. Если же админ прокосячил, и выставил в инет 139, 445 - так хоть в секурити логе он сможешь увидеть ошибки аутинтификации с удалённого хоста.

> Как говориться: "Волков бояться - в лес не ходить".

Ну мыж выставляем в инет и www, и smtp, и dns.... Так вот поинт таков - ну чем 135 в принципе более подвержен интружн? Чего там "внутри"?
думается, изначальным советчикам твоим было просто лень вникать 16.08.04 17:49  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> > Ну да, без разрешения соединений на динамически
> > распределяемые порты RPC сервера открытие порта 135 не
> > имеет никакого смысла.
> Вот это я и хотел услышать от профессионалов.
> Отсюда следует, что по крайней меречасть рисков,
> связанных с возможностью удалённого выполнения совершенно
> "штатных" процедур в деструктивных целях снимается. В этом
> и был мой поинт, когда мне объясняли, что открытие 135
> порта однозначно означет возможность хакнуть.

сабж.
а вообще - don't trouble trouble until trouble troubles you (~c)
135..139 это первым делом, и tcp, и udp.
имхо, разумеется.

опять же трафик на броадкастах съэкономишь :)
мне помнится полно шита с диал-апа МТУшного валилось, писал даже тут.


> Ну мыж выставляем в инет и www, и smtp, и dns.... Так вот
> поинт таков - ну чем 135 в принципе более подвержен
> интружн? Чего там "внутри"?

а не нужно RPC в нет выставлять. совсем нет такой необходимости. (кто хочет спорить - слушаю внимательно). все что нужно, как уже было сказано, через тот же VPN делается - волосы остаются шелковисты.
Прикрыто это у меня..... Мне по-существу интересно.;((( 17.08.04 01:13  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> а вообще - don't trouble trouble until trouble troubles you
> (~c)
> 135..139 это первым делом, и tcp, и udp.
> имхо, разумеется.

Прикрыто это у меня..... Мне по-существу интересно.;(((
Разве это запрещено спрашивать в форуме.

> а не нужно RPC в нет выставлять. совсем нет такой
> необходимости. (кто хочет спорить - слушаю внимательно).
> все что нужно, как уже было сказано, через тот же VPN
> делается - волосы остаются шелковисты.

Всё это прикрыто. И даже необходимости нет в RPC в инете.
А чего тут спорить? Полностью согласен. 16.08.04 20:03  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> а не нужно RPC в нет выставлять. совсем нет такой
> необходимости. (кто хочет спорить - слушаю внимательно).
> все что нужно, как уже было сказано, через тот же VPN
> делается - волосы остаются шелковисты.

А чего тут спорить? Полностью согласен.
Если клиентам требуется пользовать какой-нибудь COM компонент через инет, то IMHO, в этом случае лучше всего поставить у себя маленький web сервер, который, взаимодействуя с COM компонентом, будет выполнять необходимую работу, а браузер клиента будет играть роль thin client'а.
Den, да не выставляю я эти порты в инет. Конечно же... 17.08.04 01:09  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Den, да не выставляю я эти порты в инет. Конечно же нет;))))
Мне, понимаешь, как бы сказать - интересно, что внутри;))))

> Если клиентам требуется пользовать какой-нибудь COM
> компонент через инет, то IMHO, в этом случае лучше всего
> поставить у себя маленький web сервер, который,
> взаимодействуя с COM компонентом, будет выполнять
> необходимую работу, а браузер клиента будет играть роль
> thin client'а.

Да так и делают виндозники.
1) smtp это просто smtp, dns - это просто dns, через RPC же... 15.08.04 06:47  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Ну мыж выставляем в инет и www, и smtp, и dns.... Так вот
> поинт таков - ну чем 135 в принципе более подвержен
> интружн?
1) smtp это просто smtp, dns - это просто dns, через RPC же в винде много чего работать может, и если в чем нить дырка - все.
2)rpc является более "лакомным" кусочком для хакеров потому дыры в нем ищут лучше. Потому что smtp и dns серверы стоят не у всех, кроме того они могут быть не от мс, 139й порт нетбиоса вообще винды в инет не открывают по дефолту а если что его можно отключить на выбранных интерфейсах. epmap же биндится на INADDR_ANY и закрыть его можно только файрволлом.
3)Потому что в нем уже нашли много дыр.. Репутация у него хреновая.

Чего там "внутри"?
Да что угодно. Банальный фрагмент кода типа-
recv(s,buf,0xffff,0);
printf(buf);
-уже багоопасен. Переполнение это не нечто концептуальное, а просто недоучет программистом всех возможных ситуаций в любом месте кода.
теоретически 13.08.04 12:52  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
если создать ACL на брендмауэре, разрешив с внешней стороны подключения только с определенных ИП, то работать в такой ситуации можно совершенно спокойно. Другое дело что иногда очень трудно предсказать с какого ИП тебе вдруг понадобится подключиться к хосту
если же разрешить подключения с любого ИП и понадеяться только на аутенфикацию, то это может привести к нежелательным результатам. Тем более что раньше уже были обнаружены ошибки, позволяющие отправлять хост в перезагрузку посылая специально сформированные пакет на порт RPC, и выполнить эту операцию мог любой кто подключался к порту.
Да согласен. Как не согласиться.... Однако я хотел узнать не... 14.08.04 01:59  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> если создать ACL на брендмауэре, разрешив с внешней стороны
> подключения только с определенных ИП, то работать в такой
> ситуации можно совершенно спокойно. Другое дело что иногда
> очень трудно предсказать с какого ИП тебе вдруг понадобится
> подключиться к хосту
> если же разрешить подключения с любого ИП и понадеяться
> только на аутенфикацию, то это может привести к
> нежелательным результатам.

Да согласен. Как не согласиться.... Однако я хотел узнать не просто про "нежелательные" результаты, а про механизмы нежелательности ;))
Кроме того, у меня вообще прикрыт 135 порт, как и всё остальное.


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

Так этож самое главное! Про это я и хотел узнать. Что за мезанизЬмы используют атакеры. И как это можно исполльзовать для того, чтобы заслать виря, к примеру !
1




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


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