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

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