Показать полную графическую версию : [решено] Как закрыть доступ к общим папкам дисков по сети (с$)
vasketsov
19-11-2002, 17:17
А можно подробно описать, что есть и что надо?
А то как понять закрыть от просмотра?
Сделай шару с знаком $ тоды её никто видеть не будет а те кому надо подключи как сетевой диск (net use) еще вариант через политику безопасности убери доступ кому не надо они просто ничего сделать не смогут.
Andrew Denny
20-11-2002, 10:47
Guest
По-моему не закроешь. Приоритет у сервера
Сервер не причем. Админ всегда сможет зайти. Шару С$ не убъешь. Доверяйте админу и строго за ним следите :wink:
vasketsov
20-11-2002, 11:43
Andrew Denny
Админ всегда сможет зайти
Неверно, для этого существуют файрволы.
Шару С$ не убъешь
Еще более неверно.
lepa
убери доступ кому не надо они просто ничего сделать не смогут
Если только не смогут попроавить эту самую политику.
vasketsov
Интерестно узнать как сможет пользователь домена без админовских прав поменять политику, ежели можа то прошу объяснить.
vasketsov
20-11-2002, 13:23
Вообще-то мне пока что неизвестна правильная формулировка задачи, потому распространять решение на админов или нет - тоже неизвестно.
Формулирую задачу:
Надо опровергнуть цитату: "Админ всегда сможет зайти. Шару С$ не убъешь. Доверяйте админу и строго за ним следите "
Определяющим здесь является то, что Админ - это не конкретный исполнитель, а тот кто обладает паролем Админа. В конкретной ситуации паролем обладает несколько людей. Дольше можно не объяснять.
Надо закрыть диски (или их часть) Раб Станции на просмотр, оставаясь в сети домена для работы с прикладными задачами.
Andrew Denny
21-11-2002, 09:29
Guest
Надо опровергнуть цитату
Васкецов здесь уже опровергнул некоторые моменты, но все равно, что-то здесь не так. Можно действительно закрыть машину файрволлом. Но его-то тоже нужно настроить и им управлять. Админ есть админ.
паролем обладает несколько людей
А вот это уже криминал. Один человек - один пароль. Это закон.
В конце концов можно удалить группу доменных админов из группы локальных (так ставится по умолчанию при вводе машины в домен) и прописать там одного конкретного админа - доменного или локального. И он будет управлять всеми правами и политиками на этой машине. Ну путь ответственный менеджер станет админом на этой машине, а заодно научится всей нашей премудрости :wink:. Или наймет локальное КГБ, и им будут платить за то, что они всех подозревают. Ну не бывает ИМХО по другому.
vasketsov
21-11-2002, 17:56
Andrew Denny
Один человек - один пароль. Это закон
Существуют определенные задачи, которые должны иметь возможность выполнять несколько человек и для которых необходимо поддерживать бесперебойность в работе. Пример - пароль рута на веб-сервере, должен храниться в сейфе, и возможность им пользоваться должна быть как минимум у того, кто в ДАННЫЙ МОМЕНТ отвечает за его работу - сегодня один дежурит, завтра другой.
Админ всегда сможет зайти. Шару С$ не убъешь. Доверяйте админу и строго за ним следите
1) зайти всегда сможет? нет, не всегда. локальный комп имеет свою политику безопасности, которая в данном случае должна отличаться от остальной политики. Локальный доступ блокируется элементарно, удаленный - тоже, остается только одна дыра - власть имеет тот, кто пишет логон-скрипт и правит профиль. Профиль делается локальным, логон-скрипт запрещается административно как класс (все равно там обычно только время правится). Если надо совсем жестко и жестоко - смотрим что за трафик по каким портам идет и выборочно натравливаем на них локальный файрвол (на котором запрещаем удаленное администрирование, и файером можно будет рулить только локально).
2) C$ убивается а) запрещением службы сервера, б) параметрами AutoShareWks и AuoShareServer соответственно. Для включения назад придется править удаленно реестр и запрещать удаленный доступ, что тоже решаемо. В конце концов, группы админов домена и юзеров домена выкидываются из всех локальных групп.
3) А что тут опровергать?
vasketsov
Классно обьяснил!!! Доходчиво!!!
Andrew Denny
vasketsov прав C$ можно убить!!!
Andrew Denny
22-11-2002, 09:47
J Fox
vasketsov прав C$ можно убить!!!
Да согласен я, согласен! Напали, понимаешь... ;)
vasketsov
Спасибо!
Все это здорово. Особенно пп. 1 и 2.
Но в связи с моим первым сообщением и вторым в нем предложением, как бы объснить все это поподробнее.
Пока я понял, что проблема решаема. Не понял как.
vasketsov
22-11-2002, 15:26
Guest
Ну прямо дети, чесслово, где нормальное описание проблемы?
Комп обязательно должен быть в домене, это надо только лишь для того, чтобы пользоваться другими ресурсами, или существует действительно веская причина для этого?
Доступ закрывать из сети для всех вообще или выборочно?
Какой именно доступ закрывать? Удаленное управление, просмотр расшаренных папок?
говорите точно, сколько весить.
Комп в домене потому что работает с рядом программ на сервере, например с почтовой. Задача: запретить доступ с домена на комп и на просмотр и на управление ессно.
vasketsov
25-11-2002, 14:08
Guest
например с почтовой
Для этого в одном домене необходимости нет.
Еще есть причины чтоб оставить его там?
Активнее, если вывести из домена - все будет совсем просто.
...а так ли уж вам нужно заходить в домен???
...что бы читать почту не обязательно сидеть в домене... настраивайте по нормальному почтовый клиент, просто каждый раз при загрузке клиента вам придётся набирать свой пароль... подключать шары на серваке автоматом можно с помощью скрипта в автозагрузке... net use вам в помощь... а остальное как говорили выше...
Guest
Никак, только остановив LanmanServer aka Служба сервера.
:o !!! К А Р А У Л !!! Минисофт в полит целях зашарила наши с Вами ресурсы! Ребята, пока не поздно - переходите на великий LINUX :biggrin: . Форточки до добра не доведут...
Да у меня такая же проблема.. злобные админы моей локалки безжалостно шарятся по моему компу. Я закрываю эти ресурсы, а они снова их открывают. Запускают мне на комп dmadmin и dmremote и делают с моим компом все что хотят. Издеватся по всякому, да в довесок еще сидюк туда-обратно дергают.
Скажите как избавится от нападков таких вот....админов...
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.