configurações PUBLIC padrão

Question

alguém sabe de algum risco de segurança com as configurações PUBLIC padrão para o sql 2005/8?

Eu executei o sp_helprotect e ele listou as concessões PUBLIC, e agora eu tenho um auditor me dizendo que eu tenho um risco de segurança porque o PUBLIC tem acesso às informações do sistema. Antes de começar a apresentar o meu caso, eu queria ver se alguém tem algum link ou informação que possa fornecer que detalharia como as configurações padrão permitem um risco de segurança.

para o registro, o auditor mencionou que essas configurações permitem a capacidade de quebrar senhas, pois elas podem exibir o hash da senha. Eu não consegui verificar se a configuração permite essa capacidade de ver essas informações através das exibições do catálogo sys.

obrigado antecipadamente

    

Answer 1

Em 2000, o papel público tem acesso a muito mais do que em 2005 em diante - esta pode ser a fonte dos problemas do auditor. A separação do usuário / esquema deve cuidar da maioria dos problemas, mas você deve criar um usuário com permissões mínimas e ver o que ele pode ver. Você vai querer tentar:

master.sys.databases (e qualquer outra coisa que possa fornecer informações sobre o que está armazenado na instância) master.dbo.syslogins (que contém os hashes de senha - sysxlogins em 2000)

E você também quer mudar todos os XPs no mestre para que o papel público não tenha permissão de execução em nenhum deles. Há um artigo e um código que fará isso aqui .

Note que NÃO é recomendado alterar a função pública em si de forma alguma.

Espero que isso ajude!

PS Se você retornar um NULL para a senha na tabela syslogins, é porque o login não está usando a autenticação do SQL. Usar o Windows apenas é uma boa maneira de remover esse risco, mas você ainda precisa ter uma senha para a conta SA (desativada).

    

Answer 2

Aqui está um aritlo BOL explicando como a função pública afeta a visibilidade dos metadados para todos os usuários: link

Há algumas coisas que normalmente precisam ser visíveis para todos ou as coisas vão quebrar (sys.databases é um dos exemplos, mesmo que não esteja listado neste artigo - por razões históricas todos podem recuperar a lista de todos os bancos de dados em o servidor, mas você pode, naturalmente, revogar essa permissão). As coisas tendem a ficar engraçadas quando você começa a revogar o acesso público a alguns metadados.

Para dar um exemplo: as coisas quebrarão se você revogar a permissão pública para selecionar sys.databases. A maneira correta de fazer isso é REVOGAR EXIBIR QUALQUER BANCO DE DADOS de público - então sys.databases será "filtrado" e você verá apenas os bancos de dados para os quais você tem permissões. Mas isso não oferece nenhuma segurança real, pois qualquer um pode enumerar todos os bancos de dados fazendo o SELECT DB_NAME (X) e fornecendo valores arbitrários para o X (essa é uma lacuna conhecida).

E, em termos de senhas, na configuração padrão do SQL2005 e do SQL 2008, por meio da função pública, você pode ver apenas dois logins por meio do sys.syslogins: yourself e sa. E você não verá o hash de senha para nenhum dos dois. Portanto, obter hashes para quebrar dessa maneira não é uma opção. E quebrar esses hashes requer uma abordagem de força bruta de qualquer maneira, por isso só funciona para senhas fracas ou de dicionário.

Minha experiência com os auditores é que eles tendem a criar uma confusão sobre pequenas coisas, como permissões públicas, mas perdem a grande importância. YMMV.

HTH