|
|
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Что может произойти плохого, если удалить пользователя Guest из БД master ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 10:04:22 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Я хочу удалить guest по причине безопасности, т.к. группе Public (и соответственно guest) разрешено многое в master, включая установки настроек сервера через sp_MSSetServerProperties ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 10:53:00 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Удалить Guest из БД master штатным способом вам не удастся. Но если все же изголиться, и удалить, то ни кто кроме SA не сможет работать с сервером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 10:54:09 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Т.е. guest для master - архиважен и очень многое в SQL Server завязано на скромного guest ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:00:14 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Guest - важная персона. Он будет добавляться во все новые базы, даже если его убить в model. Его можно убить в любой базе, кроме master. Но по идее, guest обладает на мастере ровно таким набором прав, чтобы дать возможность работать пользователям на сервере, и при этом Вам оставаться спокойным за безопасность сервера. Без GUEST на master у Вас сервер будет обслуживать только SA ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:04:14 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Если обратите внимание, user guest не связан ни с одним login. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:08:46 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
2 fima: О чем это должно нам говорить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:17:47 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Эта фраза говорит о том что, я ручатся не берусь, :) но думаю, что на безопасность это не влияет, так как зайти под guest в MSSQL невозможно, и он является уникальным, попробуйте заведите пользователя без логина. Поэтому Гостья, я думаю, может не беспокоится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:28:31 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Если у логина нет на базе пользователя, ему автоматом дается право гостя на этой базе. Если гость не удален. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:31:48 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
2Андрей Сергеев. Да верно, не подумал, ну что ж, тогда можно посоветовать, отключить из роли public в master, то что представляется опасным, и помнить, что с master, в таком случае, может работать только dbo то есть sa. Т.е. повторил Вашу мысль :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:38:37 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Любой пользователь SQL Server может выполнить любую хранимую процедуру в master, если такое право дано роли Public (например sp_who) - такая дыра в безопасности ! Получается DBA должен пройтись по всем опасным с точки зрения безопасности объектам и отнять у них право для Public ? И повторять эту операцию после каждого Service Pack (может быть через скрипт) ? Я правильно понимаю ситуацию ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:47:12 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Прикол в том, что любое приложение,когда происходит коннект, первым делом бросается запускать всякие дурацкие процедуры из мастера(типа sp_server_info).И набор этих процедур зависит от инструментария,на котором это приложение делалось.Так,что прежде чем лишать паблик прав,ИМХО необходимо оттрэйсить коннект к серверу и выяснить, чо он там запускает,и на что нельзя урезать права. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 11:56:15 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
2Гостья Любой пользователь SQL Server может выполнить любую хранимую процедуру в master Не сочтите за труд - покажите на примере. Скажем попробуйте с помощью той же sp_MSSetServerProperties действительно изменить режим запуска сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 12:02:06 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Пример exec sp_addlogin 'rex' заходим в QA под rex, и выполняем sp_MSSetServerProperties 0. Заходим в EM и видим, что в случае ребута наш сервер уже не запустится автоматом :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 12:18:02 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
sp_MSSetServerProperties действительно не достаточно защищена. Об этом стоит написать в Microsoft. P.S. Вообще-то доменный эккаунт, под которым запускается SQL Server не должен иметь права записи в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 12:29:48 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
могу добавить к сообщению jimmers что не следут допускать чтоб sqlserver крутился от аккаунта SYSTEM... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 12:49:30 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Мда, jimmers прав, sp_MSSetServerProperties - это действительно упущение. А права на ключ HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\MSSQLServer по описанию в BOL должны быть. Но вот почему нет проверки в самом sp_MSSetServerProperties - это действительно вопрос. Полагаю из-за того, что процедура недокументирована ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 13:02:34 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Cumulative Patch for SQL Server (Q316333) Originally posted: October 02, 2002 вчерашний security fix это дело не исправляет. у кого SQL лицензионный? Стучитесь в MS :) Пусть фиксят! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 16:49:55 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Возвращаясь к sbj.... Ответ, по моему, однозначный из мастера его удалять ни-ни!!!! 2 Андрей Сергеев <...Он будет добавляться во все новые базы, даже если его убить в model. Его можно убить в любой базе, кроме master...> С одной строны да, guest есть в любой БД (есть соответствующая запись в sysusers), но воспользоваться этой учетной записью Вы несможете пока не сделаете sp_adduser 'guest' после этого все userа подключившиеся к MS SQL имеют доступ к этой БД (в которой выполнили sp_adduser 'guest') Кстати по умолчанию (после инсталяции MS SQL ) guest имеется в БД master, msdb, tempdb,pubs , Northwind В model его нет. И напоследок о небольшой грабле. Несколько месяцев назад наступили них (на грабли) с этим гостем... по какой то причине в одной БД пропала запись про него из sysusers... В результате при подлючении к MS SQL с правами пользователя отличными от sa появилась следующая беда. В утилитах, в которых есть возможность выбрать БД на сервере из списка (а это EM, QA, ODBC Administrator и т.п) При открытии этого списка на сервере выполняется проца sp_hasdbaccess. так вот если права ниже чем sa :-) этот список мог открываться минут по пять!!!! Добавили гостя (не с помощью sp_adduser а напрямую INSERT INTO sysusers.... Values ....(!)) проблема решилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2002, 17:59:27 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
Об уязвимости 2 хранимых процедур из Master sp_MSSetServerPropertiesn and sp_MSsetalertinfo написано здесь http://securitylab.ru/?ID=32737 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2002, 10:45:48 |
|
||
|
Удаление Guest из master
|
|||
|---|---|---|---|
|
#18+
А о том, как это легко обезопасить тут? Лекарство от страха ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2002, 10:57:31 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32055106&tid=1819862]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 349ms |
| 0 / 0 |
