Categorizando aplicativos e provedores de serviços em camadas

O Winsock 2 é compatível com protocolos em camadas. Um protocolo em camadas é aquele que implementa apenas funções de comunicação em níveis superiores, ao mesmo tempo em que depende de uma pilha de transporte subjacente para a efetiva troca de dados com um ponto de extremidade remoto. Um exemplo de um protocolo em camadas ou um provedor de serviços em camadas seria uma camada de segurança que adiciona protocolos ao processo de estabelecimento de conexão para realizar a autenticação e estabelecer um esquema de criptografia mutuamente acordado. Normalmente, esse protocolo de segurança exigiria os serviços de um protocolo de transporte confiável subjacente, como TCP ou SPX. O termo "protocolo base implementado pelo provedor base" refere-se a um provedor Winsock que implementa um protocolo, como TCP ou SPX, capaz de realizar comunicações de dados com um ponto de extremidade remoto. O termo "protocolo em camadas" é usado para descrever um protocolo que não pode funcionar sozinho. Esses protocolos em camadas são instalados como LSPs (provedores de serviços em camadas) do Winsock.

Um exemplo de um LSP é o Microsoft Firewall Client Service Provider instalado como parte do Internet Security and Authentication Server (ISA) nos clientes. O Provedor de Serviços do Cliente de Firewall da Microsoft é instalado nos provedores base do Winsock para TCP e UDP. Uma DLL (biblioteca de vínculo dinâmico) no software Cliente de Firewall do ISA torna-se um provedor de serviços em camadas do Winsock usado por todas as aplicações do Winsock de forma transparente. Dessa forma, o LSP do Cliente de Firewall do ISA pode interceptar chamadas de função do Winsock de aplicativos cliente e, em seguida, rotear uma solicitação para o provedor de serviços base original se o destino for local, ou para o serviço de firewall em um computador do ISA Server se o destino for remoto. Um LSP semelhante é instalado como parte do Microsoft Forefront Firewall Service e do cliente TMG (Threat Management Gateway) em clientes.

Durante a inicialização do LSP, o LSP deve fornecer ponteiros para várias funções de SPI (interface do provedor de serviços) do Winsock. Essas funções serão chamadas durante o processamento normal pela camada diretamente acima do LSP (seja outro LSP ou Ws2_32.DLL).

É possível definir categorias de LSP com base no subconjunto de funções SPI que um LSP implementa e na natureza do processamento adicional executado para cada uma dessas funções. Ao classificar os LSPs, assim como classificar aplicativos que usam soquetes Winsock, torna-se possível determinar seletivamente se um LSP deve estar envolvido em um determinado processo em tempo de execução.

No Windows Vista e versões posteriores, é disponibilizado um novo método para categorizar tanto os Provedores de Serviços Camadas Winsock quanto os aplicativos, permitindo que apenas determinados LSPs sejam carregados. Existem vários motivos para adicionar esses recursos.

Um dos principais motivos é que certos processos críticos do sistema, como winlogon e lsass, criam soquetes, mas esses processos não usam esses soquetes para enviar tráfego na rede. Portanto, a maioria dos LSPs não deve ser carregada nesses processos. Também foram documentados vários casos nos quais LSPs com bugs podem causar falhas no lsass.exe. Se o lsass falhar, o sistema forçará um desligamento. Um efeito colateral desses processos do sistema carregarem LSPs é que esses processos nunca são encerrados. Portanto,o quando um LSP é instalado ou removido, é necessário reiniciar.

Um motivo secundário é que existem casos em que os aplicativos podem optar por não carregar determinados LSPs. Por exemplo, alguns aplicativos podem não querer carregar LSPs criptográficos, o que poderia impedir a comunicação do aplicativo com outros sistemas que não têm o LSP criptográfico instalado.

Por fim, as categorias de LSP podem ser usadas por outros LSPs para o local exato na cadeia de protocolo Winsock onde devem se instalar. Durante anos, vários desenvolvedores de LSP têm desejado uma maneira de saber como um LSP se comportará. Por exemplo, um LSP que inspeciona o fluxo de dados preferiria estar acima de um LSP que criptografa os dados. É claro que esse método de categorização de LSP não é à prova de falhas, já que depende dos LSPs de terceiros para se categorizarem adequadamente.

A categorização de LSP e outros aprimoramentos de segurança no Windows Vista e versões posteriores são projetados para ajudar a impedir que os usuários instalem involuntariamente LSPs mal-intencionados.

Categorias de LSP

No Windows Vista e versões posteriores, um LSP pode ser classificado com base em como ele interage com chamadas e dados do Windows Sockets. Uma categoria de LSP é um grupo identificável de comportamentos em um subconjunto de funções de SPI do Winsock. Por exemplo, um filtro de conteúdo HTTP seria categorizado como um inspetor de dados (na categoria LSP_INSPECTOR). A categoria LSP_INSPECTOR inspecionará (mas não alterará) parâmetros das funções de SPI de transferência de dados. Um aplicativo pode consultar a categoria de um LSP e optar por não carregar o LSP com base na categoria de LSP e no conjunto permitido de categorias de LSP pelo aplicativo.

A tabela a seguir lista categorias nas quais um LSP pode ser classificado.

Um LSP pode pertencer a mais de uma categoria. Por exemplo, um LSP de firewall/segurança pode pertencer às categorias inspetor (LSP_INSPECTOR) e firewall (LSP_FIREWALL).

Se um LSP não tiver um conjunto de categorias, considera-se que está na categoria Todos os Outros. Essa categoria de LSP não será carregada em serviços ou processos do sistema (por exemplo, lsass, winlogon e muitos processos svchost).

Categorizando LSPs

No Windows Vista e versões posteriores, várias novas funções estão disponíveis para categorizar um LSP:

• WSCGetProviderInfo
• WSCGetProviderInfo32
• WSCSetProviderInfo
• WSCSetProviderInfo32

Para categorizar um LSP, a função WSCSetProviderInfo ou WSCSetProviderInfo32 é chamada com um GUID para identificar a entrada oculta do LSP, a classe de informações a ser definida para essa entrada de protocolo do LSP e um conjunto de sinalizadores usados para modificar o comportamento da função.

A função WSCGetProviderInfo ou WSCGetProviderInfo32 é usada de forma semelhante para recuperar os dados associados a uma classe de informações para um LSP.

Categorizando aplicativos

No Windows Vista e versões posteriores, várias novas funções estão disponíveis para categorizar um aplicativo:

• WSCGetApplicationCategory
• WSCSetApplicationCategory

Para categorizar um aplicativo, a função WSCSetApplicationCategory é chamada com o caminho de carga para a imagem executável, a fim de identificar o aplicativo, os argumentos de linha de comando usados ao iniciar o aplicativo e as categorias de LSP permitidas para todas as instâncias deste aplicativo.

A função WSCGetApplicationCategory é usada de forma semelhante para recuperar as categorias de LSP (provedor de serviços em camadas) associadas a um aplicativo.

Determinação de quais LSPs são carregados

A etapa final da categorização de LSPs envolve determinar quais LSPs serão carregados em quais processos. Quando um processo carrega o Winsock, são realizadas as seguintes comparações entre a categoria do aplicativo e as categorias dos LSPs instalados:

• Se o aplicativo não estiver categorizado, permite-se que todos os LSPs sejam carregados no processo.
• Se tanto o aplicativo quanto o LSP tiverem categorias atribuídas, todas as seguintes condições devem ser verdadeiras:

  Pelo menos uma das categorias de LSP está presente nas categorias especificadas do aplicativo.
  Somente as categorias especificadas nas categorias do aplicativo estão especificadas nas categorias dos LSPs. Por exemplo, se o aplicativo especificar uma categoria, ela deverá estar na categoria do LSP.
  Se a categoria LSP_SYSTEM estiver presente na categoria do aplicativo, ela também deverá estar presente nas categorias do LSP.

Considere o seguinte exemplo:

O aplicativo Foo.exe é categorizado como LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS. O aplicativo Bar.exe é categorizado como LSP_FIREWALL + LSP_CRYPTO_COMPRESS. Existem quatro LSPs instalados no sistema:

• O LSP1 definiu uma categoria de LSP_SYSTEM.
• O LSP2 não tem categorias definidas, portanto, sua categoria é zero.
• O LSP3 definiu uma categoria de LSP_FIREWALL.
• O LSP4 definiu categorias de LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS + LSP_INSPECTOR

Neste exemplo, o aplicativo Foo.exe carregaria apenas o LSP1, enquanto o aplicativo Bar.exe carregaria LSP3.

Determinando provedores Winsock instalados

O Software Development Kit (SDK) do Microsoft Windows inclui um programa Winsock de exemplo que pode ser usado para determinar os provedores de transporte Winsock instalados em um computador local. Por padrão, o código-fonte desse exemplo Winsock está instalado no seguinte diretório do SDK do Windows para Windows 7:

C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\NetDs\winsock\LSP

Este exemplo é uma ferramenta utilitária para instalar e testar provedores de serviços em camadas. No entanto, também pode ser usada para coletar informações detalhadas do catálogo Winsock em um computador local de maneira programática. Para listar todos os provedores Winsock atuais, incluindo provedores base e provedores de serviços em camadas, compile este exemplo Winsock e execute o seguinte comando no console:

instlsp -p

A saída será uma lista de provedores Winsock instalados no computador local, incluindo provedores de serviços em camadas. A saída lista a ID do catálogo e o nome da cadeia de caracteres do provedor Winsock

Para coletar informações mais detalhadas sobre todos os provedores Winsock, execute o seguinte comando no console:

instlsp -p -v

A saída será uma lista de estruturas WSAPROTOCOL_INFO compatíveis com o computador local.

Para obter uma lista apenas os provedores de serviços em camadas instalados no computador local, execute o seguinte comando no console:

instlsp -l

Para mapear a estrutura do LSP, execute o seguinte comando no console:

instlsp -m