Um sniffer na comunicação do SQL Server

Em qualquer cenário onde há comunicação remota do SQL Server com outros computadores, se torna fácil identificar os dados que são trafegados na rede utilizando um sniffer, principalmente quando não há muita dificuldade em uma máquina entrar na rede onde esta o SQL Server.

Para mostrar que a comunicação entre máquinas clientes e o SQL Server não é muito segura se não há utilização de criptografia, utilizarei o Microsoft Network Monitor 3.4 com um parse específico para obter informações do SQL Server, mostrando os dados trafegando pela rede.

Iniciando o Network Monitor, criaremos uma nova aba de capturada (New capture tab):

Definindo em ‘Tools\Options’ o parse do SQL Server:

Iniciaremos a captura e executando algumas consultas em um SQL Server, já teremos informações para analisar:

Basicamente teremos informações sobre qual protocolo utilizando (TCP, TDS…), qual a ação realizada (SQLBatch, Response, Flags, Prelogin…) e o SPID da conexão (ex.: 52):

Como exemplo de um TDS:SQLBatch, no qual executei o comando “SELECT name FROM sys.tables” no SQL Server Management Studio (SSMS), será fácil encontrar o comando nos detalhes da comunicação:

E um TDS:Response, no qual tive o seguinte retorno no SSMS:

E no Network Monitor, também é possível visualizar os dados trafegados:

Fiquem tranquilos, próxima semana publico a solução para este cenário! (ver artigo sobre SSL no SQL Server)

Programas utilizados:

Microsoft Network Monitor 3.4
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en

Network Monitor Open Source Parsers (NetworkMonitor Parsers forSQLServer)
http://nmparsers.codeplex.com/releases/view/64054

Introdução ao Service Broker – Parte 2 – Diálogo e Permissões

Caminhando com o segundo artigo sobre Service Broker, entenderemos como criar um diálogo entre dois bancos de dados na mesma instância do SQL Server. Ao contrário do monólogo, que foi apresentado no artigo anterior, os diálogos que requerem a interação entre dois bancos precisam, além das configurações padrões do Service Broker, também da opção “TRUSTWORTHY” habilitada:

USE [master];

CREATE DATABASE DB01;

ALTER DATABASE DB01
	SET ENABLE_BROKER;

ALTER DATABASE DB01
	SET TRUSTWORTHY ON;

CREATE DATABASE DB02;

ALTER DATABASE DB02
	SET ENABLE_BROKER;

ALTER DATABASE DB02
	SET TRUSTWORTHY ON;

GO

USE DB01;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'su93rS3nh4?db01';

USE DB02;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'su93rS3nh4?db02';

GO

Para que os serviços que realizarão este diálogo possam entender as mensagens enviadas e recebidas, assim como os contratos estabelecidos, é necessário que haja nos dois bancos de dados a mesma definição de contratos e tipos de mensagens.

USE DB01;

CREATE MESSAGE TYPE Requisicao
	VALIDATION = WELL_FORMED_XML;

CREATE MESSAGE TYPE Resposta
	VALIDATION = WELL_FORMED_XML;

CREATE CONTRACT Contrato (
	Requisicao SENT BY INITIATOR,
	Resposta SENT BY TARGET
);

USE DB02;

CREATE MESSAGE TYPE Requisicao
	VALIDATION = WELL_FORMED_XML;

CREATE MESSAGE TYPE Resposta
	VALIDATION = WELL_FORMED_XML;

CREATE CONTRACT Contrato (
	Requisicao SENT BY INITIATOR,
	Resposta SENT BY TARGET
);

Por fim, estabelecemos uma fila e serviço para requisições no banco de dados que receberá a interação, e também uma fila e serviço para respostas no banco de dados que inicia a interação:

USE DB02;

CREATE QUEUE FilaRequisicao
	WITH STATUS = ON;

CREATE SERVICE ServicoRequisicao
	ON QUEUE FilaRequisicao (Contrato);

USE DB01;

CREATE QUEUE FilaResposta
	WITH STATUS = ON;

CREATE SERVICE ServicoResposta
	ON QUEUE FilaResposta (Contrato);

GO

Terminada a estrutura para o diálogo, iniciamos a interação a partir do serviço de resposta para com o serviço de requisição:

USE DB01;

DECLARE @Mensagem XML = 'Requisição'
, @MensagemId UNIQUEIDENTIFIER;

BEGIN DIALOG CONVERSATION @MensagemId
	FROM SERVICE ServicoResposta
	TO SERVICE 'ServicoRequisicao'
	ON CONTRACT Contrato;

SEND ON CONVERSATION @MensagemId
	MESSAGE TYPE Requisicao(@Mensagem);

Recebemos a mensagem da fila de requisições e enviamos uma mensagem de respostas:

USE DB02;

DECLARE @Mensagem XML
, @MensagemId UNIQUEIDENTIFIER;

RECEIVE TOP(1)
	@Mensagem = [message_body],
	@MensagemId = [conversation_handle]
FROM FilaRequisicao;

SELECT @MensagemId, @Mensagem;

IF @MensagemId IS NOT NULL
BEGIN
	SET @Mensagem = 'Resposta';

	SEND ON CONVERSATION @MensagemId
		MESSAGE TYPE Resposta(@Mensagem);
END

Por fim, recuperamos da fila de respostas a mensagem, concluindo a comunicação:

USE DB01;

DECLARE @Mensagem XML
, @MensagemId UNIQUEIDENTIFIER;

RECEIVE TOP(1)
	@Mensagem = [message_body],
	@MensagemId = [conversation_handle]
FROM FilaResposta;

SELECT @MensagemId, @Mensagem;

IF @MensagemId IS NOT NULL
	END CONVERSATION @MensagemId;

Permissões

Em relação os usuários que possuem acessos limitados, mas que precisam realizar as interações, só será necessário que eles tenham a permissão de CONTROL das filas dos seus respectivos bancos de dados, por exemplo:

-- Usuário que poderá ser utilizado para interações dos serviços relacionados à fila de resposta.
USE DB01;

CREATE LOGIN Maria WITH PASSWORD = 'su93rS3nh4';

CREATE USER Maria FOR LOGIN Maria;

GRANT CONTROL ON dbo.FilaResposta TO Maria;

GO

-- Usuário que poderá ser utilizado para interações dos serviços relacionados à fila de requisição.
USE DB02;

CREATE LOGIN Heitor WITH PASSWORD = 'su93rS3nh4';

CREATE USER Heitor FOR LOGIN Heitor;

GRANT CONTROL ON dbo.FilaRequisicao TO Heitor;

GO

Por fim, uma interação completa utilizando somente da permissão de CONTROL destes usuários:

USE DB01;

EXEC AS LOGIN = 'Maria';

USE DB01;

DECLARE @Mensagem XML = 'Requisição'
, @MensagemId UNIQUEIDENTIFIER;

BEGIN DIALOG CONVERSATION @MensagemId
	FROM SERVICE ServicoResposta
	TO SERVICE 'ServicoRequisicao'
	ON CONTRACT Contrato;

SEND ON CONVERSATION @MensagemId
	MESSAGE TYPE Requisicao(@Mensagem);

REVERT;

GO

USE DB02;

EXEC AS LOGIN = 'Heitor';

USE DB02;

DECLARE @Mensagem XML
, @MensagemId UNIQUEIDENTIFIER;

RECEIVE TOP(1)
	@Mensagem = [message_body],
	@MensagemId = [conversation_handle]
FROM FilaRequisicao;

SELECT @MensagemId, @Mensagem;

IF @MensagemId IS NOT NULL
BEGIN
	SET @Mensagem = 'Resposta';

	SEND ON CONVERSATION @MensagemId
		MESSAGE TYPE Resposta(@Mensagem);
END

REVERT;

GO

USE DB01;

EXEC AS LOGIN = 'Maria';

USE DB01;

DECLARE @Mensagem XML
, @MensagemId UNIQUEIDENTIFIER;

RECEIVE TOP(1)
	@Mensagem = [message_body],
	@MensagemId = [conversation_handle]
FROM FilaResposta;

SELECT @MensagemId, @Mensagem;

IF @MensagemId IS NOT NULL
	END CONVERSATION @MensagemId;

REVERT;

GO

Cross DB Ownership Chaining

Uma solução muito comum para situações onde temos um usuário que precisa executar uma procedure ou VIEW que relaciona dados de outro banco de dados, mas este usuário não deve ter acesso direto a este outro banco de dados, é utilizar a opção de Cross DB Ownership Chaining (SQL Server 2005+).

Como exemplo desta funcionalidade, vamos criar no primeiro banco de dados, uma tabela e no segundo banco de dados, uma VIEW que retorna os valores desta tabela do primeiro banco dados:

USE DB01
GO
CREATE TABLE SuperTabela (Id INT)
GO

USE DB02
GO
CREATE VIEW SuperVisao AS
SELECT * FROM DB01.dbo.SuperTabela
WHERE ID > 10
GO

Vamos criar um LOGIN para a Maria e um USER em cada um dos bancos de dados do nosso cenário:

USE [master]
GO
CREATE LOGIN Maria WITH PASSWORD = '9455w0rd'
GO

USE DB01
GO
CREATE USER Maria FOR LOGIN Maria
GO

USE DB02
GO
CREATE USER Maria FOR LOGIN Maria
GO

Em seguida, damos permissão de SELECT na VIEW que criamos ao usuário da Maria:

USE DB02
GO
GRANT SELECT ON dbo.SuperVisao TO Maria
GO

Sem Cross DB Ownership Chaining

Com o Cross DB Ownership Chaining desabilitado nos bancos de dados, primeiramente testamos se ela não tem acesso diretamente à tabela (acesso negado):

-- Desabilitando o Cross DB Ownership Chaining
USE [master]
GO
ALTER DATABASE DB01 SET DB_CHAINING OFF
GO
ALTER DATABASE DB02 SET DB_CHAINING OFF
GO

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperTabela
GO
REVERT
GO

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object ‘SuperTabela’, database ‘DB01′, schema ‘dbo’.

E testamos o acesso dela na View e teremos como retorno que ela não tem acesso a tabela:

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperVisao
GO
REVERT
GO

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object ‘SuperTabela’, database ‘DB01′, schema ‘dbo’.

Com Cross DB Ownership Chaining

Habilitamos o Cross DB Ownership Chaining, e testamos o acesso dela à tabela (acesso negado):

-- Habilitando o Cross DB Ownership Chaining
USE [master]
GO
ALTER DATABASE DB01 SET DB_CHAINING OFF
GO
ALTER DATABASE DB02 SET DB_CHAINING OFF
GO

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperTabela
GO
REVERT
GO

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object ‘SuperTabela’, database ‘DB01′, schema ‘dbo’.

Agora, testamos o acesso á VIEW, e ela terá o acesso sem problemas:

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperVisao
GO
REVERT
GO

Id
———–
(0 row(s) affected)

Caso você dar o acesso da Maria á tabela do primeiro banco de dados, não será necessário utilizar a opção “Cross DB Ownership Chaining”.

Também é possível habilitar esta opção em todo o servidor com o seguinte comando:

sp_configure 'cross db ownership chaining', 1
GO
RECONFIGURE
GO

Referências:
http://msdn.microsoft.com/en-us/library/ms188694.aspx

Habilitando SQL Authentication e o usuário “sa”

Um problema comum quando se utiliza o SQL Server é quando não é possível entrar com usuários SQL Server, exemplo o super usuário “sa”, pois durante a instalação foi configurado para Windows Authentication.

Como mencionado em um post no Fórum do MSDN: “Criei a instância, criei senha para meu login, mais quando vou entrar pela autenticação do SQL SERVER, ele dá erro, já pela da autenticação do Windows ele dá certo…”

Visto que não é possível ficar reinstalando o SQL Server, somente para trocar a autenticação de Windows Authentication para “Mixed” Authentication, segue neste post a solução para este problema.

Primeiramente é necessário entrar no SQL Server utilizando o SQL Server Management Studio. Conforme a figura abaixo, estou conectando em uma instância do SQL Server 2008 Express utilizando a autenticação Windows Authentication, mas este exemplo funciona perfeitamente no SQL Server 2005 e nas edições superiores.

 

Após conectar, clicando com o botão direito do mouse sobre a instância do SQL Server na janela Object Explorer (Atalho F8 ou Menu “View\Object Explorer”), item Properties.

 

Nesta nova janela, na aba (“página”) Security, altere “Server authentication” para “SQL Server and Windows Authentication mode”.

 

Feito isso, uma janelinha informará que para esta alteração ter efeito, será necessário que o serviço do SQL Server deve ser reiniciado. Mas isso pode ser feito depois, quando for terminada a configuração dos usuários do SQL Server, então deixe para depois.

 

Continuando na janela Object Explorer, expandindo a instância, “folder” Security\Logins, pode ser criado novos usuários do SQL Server ou seguindo o objetivo inicial deste tópico, habilitar o usuário “sa”. Conforme a figura abaixo, botão direito sobre o login “sa”, menu Properties.

 

Na nova janela, altere o password do usuário, também é possível alterar o “idioma” e o banco de dados padrão deste usuário nesta janela, entre outras funcionalidades.

 

Na aba (“página”) Status, clique na opção “Grant” em “Permission to connect to database engine” e “Enable” em “Login”.

 

Outra maneira pratica de habilitar o usuário “sa” é por meio de script, exemplo:

ALTER LOGIN sa ENABLE;
GO
ALTER LOGIN sa WITH PASSWORD = 'P@ssw0rdM0del0';
GO 

Então, agora resta reiniciar o SQL Server. Para não ter que entrar nos Serviços do Windows ou SQL Server Configuration Manager ou qualquer variante como arquivos .bat ou SQL Server Surface Area.

Uma dica é clicar com o botão direito na instância do SQL Server na janela Object Explorer e “Restart”.

 

Clique em Yes nesta próxima janelinha, para dizer que você TEM CERTEZA QUE QUER REINICIAR O SERVIÇO…

 

Agora é só conectar com o usuário “sa” para testar.

 

Até o próximo post!