TechNet Magazine > Home > Todas as edições > 2008 > June >  Segurança: Gerenciando o firewall do Windo...
Segurança
Gerenciando o firewall do Windows Vista
Jesper M. Johansson
 
À primeira vista:
  • Tipos de regra e cenários
  • Perfis de firewall
  • Regras de isolamento do domínio
  • O problema da filtragem de saída

Há pouco tempo, escrevi um artigo no meu blog sobre o firewall do Windows Vista. Essa postagem simplesmente indicava alguns dos recursos interessantes, mas não oferecia muito em termos de auxílio quanto à implantação.
Neste artigo, entro em mais detalhes sobre alguns dos recursos no firewall do Windows Vista® projetados especificamente para facilitar o gerenciamento corporativo. Além disso, também auxiliarei na forma como é possível usá-los para simplificar o trabalho e garantir mais segurança para os usuários.
Com o lançamento recente do SP1 para o Windows Vista, você poderia esperar a implantação corporativa do Windows Vista. (É comum que as empresas aguardem o lançamento do primeiro service pack até migrarem para um novo sistema operacional.) Caso seja um dos profissionais de TI que agora estejam mais seriamente em busca do Windows Vista para o ambiente corporativo, você deve observar com atenção o firewall. Depois de perceber do que o firewall do Windows Vista é capaz, você talvez queira renegociar o contrato que tem com aquele pacote de segurança de terceiros a fim de remover o firewall do pacote.

Firewalls do Windows – agora e sempre
O firewall, na versão original do Windows® XP, deixava muito a desejar. Embora atendesse adequadamente a funcionalidade de segurança em firewalls baseados em host comerciais naquele momento, ele não acrescentava nada de novo ou inovador.
A substituição que acompanhou o Windows XP SP2 foi totalmente modificada. Ela foi projetada especificamente para facilitar a capacidade de gerenciamento corporativo. O firewall do Windows XP SP2 é muito atraente, por ser leve, gerenciável de maneira centralizada, efetivo e não intrusivo. Mas, talvez o mais importante, ele faz algo muito importante: o firewall do Windows XP SP2 protege o sistema durante a inicialização.
O último aspecto é crucial. No passado, vi muitos sistemas serem infectados durante a inicialização, mesmo com um firewall ativado. Na verdade, em meio ao ponto máximo da epidemia Blaster, os índices de ataque chegavam a um a cada quatro minutos. Em outras palavras, se você deixasse um computador desprotegido na Internet, ele poderia ser infectado, em média, em quatro minutos. E se estivesse contando com um firewall que não protegesse o sistema durante a inicialização, 1 a cada 12 sistemas seria infectado nesse momento. Esses números levaram a Microsoft a garantir que o firewall do Windows XP SP2 protegesse o sistema durante a inicialização.
No Windows Vista, o firewall recebeu uma roupagem totalmente diferente. A alteração mais óbvia, do ponto de vista do gerenciamento, é que as interfaces de gerenciamento do protocolo IPsec e do firewall foram mescladas. Trata-se de uma alteração bastante lógica. O IPsec e o firewall foram projetados para bloquear coisas não permitidas. A diferença é que, no firewall, os parâmetros que definem o que é permitido não são muito granulares, e bloquear ou permitir grandes espaços de endereçamento no IPsec é complicado.
Com os dois recursos localizados em uma única interface de gerenciamento, os administradores podem usar ambas as tecnologias diretamente, menos preocupados se algo exige uma regra de IPsec ou deve ter um filtro de firewall. Você tem, essencialmente, uma única visão da superfície de ataque na rede do sistema, e isso ajuda a minimizar o risco de haver enganos.
O SP1 para o Windows Vista adiciona algumas melhorias em termos de confiabilidade aos recursos de firewall. Ele também adiciona algoritmos novos, notadamente os algoritmos do Pacote B, a serem usados em IPsec. Trata-se de um conjunto de algoritmos relacionados à criptografia, formado por AES (Advanced Encryption System), ECC (Elliptic Curve Cryptography) e SHA (Secure Hash Algorithm) 256 e 384.
Porém, o mais importante: o Service Pack 1 adiciona o suporte à NAP (Proteção de Acesso à Rede). A NAP é uma ferramenta de imposição de diretiva que garante que clientes gerenciados e não comprometidos estejam atualizados em relação às diretivas de segurança, atualizações e definições antimalware mais recentes antes de receberem a permissão para se conectar à rede. A NAP não pode impedir a conexão de hosts mal-intencionados com a rede, mas garante a total compatibilidade de todos os hosts gerenciados enquanto não estiverem ativamente comprometidos.
O firewall do Windows Vista, chamado de Firewall do Windows com Segurança Avançada, também está incluído no Windows Server® 2008. Todos os recursos também são gerenciáveis remotamente, podendo ser configurados em uma rede usando a Diretiva de Grupo.

Tipos de regra e cenários
A combinação do firewall e da funcionalidade IPsec na interface de gerenciamento significa que existem dois tipos de regra diferentes agora: regras direcionais e regras de conexão. As direcionais são regras de firewall padrão que definem o tráfego permitido na direção apropriada. As regras de conexão definem os parâmetros de proteção para conexões entre computadores. Para fazer uma analogia, as regras direcionais são um pouco parecidas com as regras de firewall que você conhece de firewalls anteriores, e as regras de conexão são mais semelhantes às regras de IPsec usadas com o firewall no Windows XP SP2.
Integrando o firewall e o protocolo IPsec na mesma interface, surgem vários cenários bastante interessantes. Por exemplo, isolar sistemas um do outro na rede é um dos conceitos de segurança mais importantes atualmente à disposição. A Microsoft chama isso de "isolamento de servidor e domínio".
O isolamento de servidor e domínio usa o protocolo IPsec e a funcionalidade de firewall. Reconhecendo isso, a nova interface de gerenciamento de firewall inclui uma funcionalidade específica nas regras de isolamento. Elas estarão adequadas se, digamos, você quiser restringir a conexão com base nos atributos dos sistemas de origem ou destino como, por exemplo, a associação do domínio.
Como se pode ver na Figura 1, o Assistente para Nova Regra de Segurança de Conexão é iniciado perguntando o tipo de regra que você deseja criar. Caso você selecione Isolamento, o assistente predefine determinadas configurações apropriadas a uma regra de isolamento.
Figura 1 Usando o Assistente para Nova Regra de Segurança de Conexão para criar uma regra de isolamento (Clique na imagem para uma visão ampliada)
Você também pode observar na Figura 1 que a regra de isolamento menciona o status da integridade. As regras usadas no isolamento de servidor e domínio são, na verdade, as mesmas usadas na NAP.
É possível impor a autenticação em alguns tipos de tráfego. Por exemplo, é provável que você não queira exigir a autenticação na resolução de DNS. Para os pontos de extremidade desse tipo de tráfego, você precisa de uma regra de isenção. Uma regra de isenção de autenticação é exatamente o que parece: ela isenta o tráfego dos requisitos do protocolo IPsec.
O nome de uma regra servidor-a-servidor está um pouco equivocado. Embora seja muito usada com servidores, ela também pode ser usada com clientes. Uma regra servidor-a-servidor simplesmente configura uma conexão para exigir autenticação. Isso é diferente de uma regra de isolamento em que ela exige não apenas a autenticação, mas também o cumprimento de alguns critérios adicionais como, por exemplo, a associação de domínio ou o estado de integridade.
Basicamente, uma regra de encapsulamento define uma VPN (rede virtual privada) site a site e o encapsulamento entre os gateways. As regras de encapsulamento raramente são usadas com o Windows Vista, porque é improvável que você use o Windows Vista em uma capacidade de gateway. É possível criar regras totalmente personalizadas. Isso permite a personalização de todos os parâmetros da regra.

Ordenação da regra
A ordenação da regra é um pouco complicada à primeira vista. A chave para compreendê-la é primeiro se esquecer da ordenação. Não é tanto uma ordenação, mas mais uma seleção correspondente. Considere o tráfego de entrada como exemplo. O tráfego de entrada que não corresponde a nenhuma regra que permita, por padrão, seu bloqueio. Você pode considerar que uma ordenação afirme "Regras de permissão são consideradas primeiro", mas essa pressuposição estaria incorreta. Se um pacote específico corresponder a regras de permissão e de bloqueio, esta última vencerá. Isso significa que a correspondência, em termos simples, é:
  1. Regras de bloqueio. Caso corresponda a uma delas, um pacote ou conexão é descartado.
  2. Regras de permissão. Caso corresponda a uma delas, um pacote ou conexão é permitido.
  3. Comportamento do perfil direcional padrão. Se nenhuma regra de bloqueio ou de permissão corresponder, o tráfego será tratado de acordo com o comportamento especificado como sendo o padrão para o tráfego naquela direção daquele perfil. Na direção de entrada em todos os perfis, isso significa bloquear o tráfego em uma configuração padrão. Na direção de saída, por padrão, isso significa permitir o tráfego na configuração padrão.
O processo correspondente é moderado por regras de bypass autenticado (IPsec). Usando esse tipo de regra, todo tráfego autenticado correspondente aos demais parâmetros da regra é permitido, independentemente da correspondência ou não em relação às demais regras. As regras de bypass autenticado são direcionais e têm a opção Substituir regras de bloqueio selecionada, como mostrado na Figura 2. Elas são consideradas primeiro a fim de permitir que o tráfego autenticado sempre chegue ao sistema. Trata-se da chave para permitir que você permita facilmente o tráfego de hosts autenticados, mas bloqueie todo o tráfego restante. É possível considerar a regra 0 na ordenação. Dessa forma, a lista da ordem de regra completa fica assim:
Figura 2 Marcando a opção Substituir regras de bloqueio para configurar uma regra de bypass autenticado (Clique na imagem para uma visão ampliada)

0. Regras de bypass autenticado
1. Regras de bloqueio
2. Regras de permissão
3. Comportamento do perfil direcional padrão

Não importa muito se há várias regras dentro de cada classe correspondente ao padrão de tráfego. Assim que uma regra corresponde ao tráfego, o processamento da regra pára.

Público, privado e no domínio
O novo firewall tem três perfis: público, privado e domínio. Por outro lado, o firewall do Windows XP SP2 apresentava dois perfis de rede: padrão e domínio. O perfil de domínio é invocado automaticamente quando o computador consegue achar o controlador de domínio. No Windows XP, o perfil padrão era usado de outra forma. Isso fornecia uma funcionalidade eficiente para um administrador de segurança, que poderia bloquear completamente o computador quando estivesse móvel e, mesmo assim, permitir toda a funcionalidade de gerenciamento remoto necessária quando estivesse na rede da organização. Mas essa abordagem apresentava determinados problemas para alguns usuários – em especial, aqueles com redes pessoais domésticas. Como o perfil padrão sempre foi usado como se o sistema não conseguisse chegar ao controlador de domínio, o sistema era bloqueado na casa do usuário.
O novo perfil privado incluído no Windows Vista ajuda a resolver esse problema. Agora quando você conectar o sistema a uma rede nova, ele irá perguntar se essa rede é pública (trata-se simplesmente do novo nome do antigo perfil padrão) ou privada e configurar o sistema de acordo. O sistema se lembra disso sempre que se conecta a essa rede em especial, com base nos parâmetros de rede apresentados a ele pelos servidores de infra-estrutura na rede. Isso não é, de modo algum, à prova de falhas, mas ajuda ao permitir que mais redes sejam corretamente bloqueadas.
A lógica de detecção para saber se o sistema está no domínio também foi aprimorada. O resultado é uma transição mais rápida e confiável, além de menos sistemas pensando se devem usar perfis públicos ou privados quando efetivamente estão no domínio.
É possível vincular regras a um tipo de rede em especial, impedindo o sistema de transportar muitas informações e tentando se conectar a sistemas em redes não confiáveis. Essa é uma área em que a integração entre o firewall e o protocolo IPsec começa a compensar.
Usando essas regras novas, é possível fornecer algumas restrições que outrora não eram possíveis. Por exemplo, durante muitos anos os invasores tentaram ataques por sedução para que os usuários estabelecem conexões de protocolo SMB (Server Message Block) – do sistema de rede do Windows – com hosts não confiáveis, o que forçaria uma seqüência de autenticação que daria a eles um par desafio/resposta que poderia ser usado na descoberta de senhas. As versões anteriores desse ataque também eram usadas no downgrade para autenticação de texto não criptografado ou a fim de refletir o par desafio/resposta do usuário novamente no computador de origem. A técnica anterior foi quebrada há alguns anos. Esta última técnica foi reduzida com o Windows XP SP2 – mas não se esqueça de que transportar pares desafio/resposta não é algo sensato.
Para impedir isso, você poderia usar uma nova função do firewall do Windows Vista: filtragem de saída. Um administrador poderia optar, por exemplo, por bloquear todas as conexões SMB de saída (aquelas que terminam nas portas TCP 135, 139, 445 e UDP 137, 138, 445) no perfil público. Isso dificultaria muito o uso de um sistema em um ataque por sedução a fim de obter pares desafio/resposta ou impedi-lo de acessar compartilhamentos de arquivos do Windows não confiáveis na Internet.
Mais uma vez, isso certamente não é à prova de falhas. Por exemplo, se o sistema já tivesse sido comprometido, essa regra não impediria que o sistema se comunicasse, uma vez que bastaria ao invasor desabilitar a regra. No entanto, pode ser muito útil como medida proteger sistemas de bom comportamento, mas potencialmente expostos.
Nesse contexto, é importante mencionar que, assim como no Windows XP SP2, somente um perfil pode estar ativo por vez no Windows Vista e no Windows Server 2008. Se houver duas interfaces de rede ativas no sistema e uma delas estiver no domínio enquanto a outra está em uma rede pública, o perfil público do firewall será aplicado a ambas. Sempre será usado o perfil mais restritivo. Como você pode imaginar, o perfil público é mais restritivo que o privado, e este último é mais restritivo que o perfil de domínio. Portanto, saiba que a regra de bloqueio SMB de saída pode interromper grande parte do tráfego em conexões VPN.
Para habilitar o tráfego em uma conexão VPN quando o computador está em uma rede pública ou privada, você cria regras direcionais que só se aplicam a interfaces VPN. Para que isso funcione, as interfaces VPN devem ser reconhecidas como tal pelo Windows. Caso você não use o servidor VPN Serviços de Roteamento e Acesso Remoto Microsoft®, teste essa funcionalidade antes de implantá-la amplamente. Trata-se basicamente de um problema com o tráfego de entrada do cliente e de qualquer regra de saída criada.

Criando regras de firewall
Criar uma regra de firewall é muito mais fácil no novo firewall. O Assistente de Nova Regra, mostrado na Figura 3, permite que você defina todos os tipos habituais de regras. E isso inclui regras predefinidas para serviços específicos.
Figura 3 Regras predefinidas no Assistente de Nova Regra (Clique na imagem para uma visão ampliada)
As regras predefinidas são especialmente importantes. O isolamento de servidor está essencialmente relacionado à restrição de serviços de forma que eles só estejam disponíveis para os sistemas que precisam usá-los. Em produtos de servidor, o SCW (Assistente de Configuração de Segurança do Windows) pode ser usado para simplificar isso, ainda que continue havendo algumas dificuldades. (Abordei o SCW na edição de março de 2008 da TechNet Magazine.)
Mas as versões do Windows do cliente não apresentavam funcionalidade semelhante até agora. Quando você usa o tipo de regra predefinida, grande parte do trabalho pesado é feita para você – a tarefa de determinar os pontos de extremidade usados por um serviço. O firewall não reconhece apenas o aplicativo, por saber qual programa o "Serviço iSCSI" representa; ele também contém regras predefinidas que descrevem uma determinada funcionalidade. Isso permite se concentrar nos computadores que precisam ser abordados em uma regra. Essa continua sendo uma tarefa difícil e demorada, mas pelo menos uma exclusiva do seu ambiente.
Também existe uma regra personalizada (disfarçada pelo menu suspenso na Figura 3) que oferece toda a flexibilidade esperada de um firewall de autenticação. Por exemplo, se quisesse uma regra que permitisse apenas o tráfego criptografado de IPsec, você selecionaria a opção para só permitir conexões seguras na página Ação do assistente mostrada na Figura 2.
Ao selecioná-la, você também tem a opção de ativar a criptografia. Se você deixar essa opção em branco, o tráfego usará ESP-NULL (carga de segurança encapsulada com uma chave NULA). Trata-se da maneira recomendável de usar o protocolo IPsec na autenticação. Ele permite que a maioria das ferramentas de gerenciamento de rede continue funcionando porque o tráfego está atravessando a rede sem criptografia, e caso você queira criptografar, basta marcar a caixa.
Em muitas situações, a criptografia do tráfego de rede não é tão importante quanto não aceitar qualquer tráfego de hosts mal-intencionados. Criptografar o tráfego na rede bloqueia um mau elemento que obteve acesso à rede por conta própria vendo o que havia no pacote. Em primeiro lugar, a exigência da autenticação pode impedir o envio do pacote e o ataque. Tudo bem, há muitas situações em que a criptografia no nível da rede é importante, mas também existem muitas outras nas quais você só precisaria de autenticação.

Criando regras de isolamento do domínio
Na maioria dos ambientes, você deseja que um número limitado de computadores possa enviar tráfego para uma estação de trabalho. Na pior das hipóteses, todas estações de trabalho devem ser configuradas com regras de isolamento do domínio. Isso era complicado no Windows XP, mas está fácil no Windows Vista.
Primeiramente, abra a ferramenta de gerenciamento de sua escolha e selecione o nó Regras de Segurança de Conexão. Em seguida, clique com o botão direito do mouse no nó e selecione Nova Regra para abrir a caixa de diálogo mostrada na Figura 1. Selecione a regra Isolamento e clique em Avançar. Agora você precisa selecionar se deseja impor ou não a regra. Em grande parte dos casos em estações de trabalho, você desejará exigir autenticação para o tráfego de entrada. Isso impede que qualquer computador que não tenha ingressado no domínio envie tráfego para a estação de trabalho. No entanto, para solicitar serviços da infra-estrutura, o sistema deve permitir a passagem não criptografada de parte do tráfego de saída. Por isso, a melhor opção é exigir a autenticação em conexões de entrada e solicitá-la em conexões de saída.
Em seguida, escolha o método de autenticação. A seleção padrão se chama, bem, Padrão – um título que não ajuda muito. É possível configurar o método de autenticação padrão de acordo com o computador nas propriedades do protocolo IPsec (acessadas clicando-se com o botão direito do mouse no nó Firewall do Windows com Segurança Avançada e selecionando as propriedades). O método de autenticação padrão sempre é Kerberos porque se trata do mais simples e mais seguro. No entanto, por uma questão de clareza, recomendo que você efetivamente o selecione ao criar suas regras. Normalmente, você deseja autenticar apenas o computador, e não o usuário também. Caso exija ambos, você talvez não consiga aceitar determinados tipos de tráfego de gerenciamento como, por exemplo, o tráfego SNMP transmitido de maneira anônima.
Depois de ter selecionado o método de autenticação, tudo o que você precisa fazer é selecionar os perfis nos quais essa regra deve estar disponível. Como se trata de uma regra que se aplica a computadores que ingressaram no domínio, os quais podem apresentar um tíquete Kerberos, não faz sentido abrir essa falha específica nos perfis Privado ou Público. Salve a regra e pronto.
As regras de isolamento básico não são mais complicadas do que isso. No entanto, para usufruir a eficiência do protocolo IPsec em termos de isolamento, você precisa implementar o isolamento de servidor até mesmo nas estações de trabalho. Fazendo isso, é possível evitar que as estações de trabalho ouçam os demais clientes. Na verdade, elas só responderão às estações de gerenciamento apropriadas. Imagine o impacto muito menor que várias interrupções de malware teriam se os sistemas do cliente tivessem se recusado a ouvir os demais clientes.

Criando scripts no firewall
O novo firewall acompanha uma API substancial que permite criar scripts para implantação e avaliação. O ideal é que você use a Diretiva de Grupo na implantação, mas como ela nem sempre está disponível, é importante contar com um conjunto apropriado de APIs para configurar o firewall. As APIs estão agrupadas no conjunto INetFWPolicy2 de APIs. O Software Development Kit e a MSDN® Library contêm mais detalhes completos sobre como usá-las, embora alguns exemplos ajudem a ilustrar o assunto.
Um exemplo comum é a necessidade de determinar se um grupo de regras está ativado. Digamos, por exemplo, que um aplicativo ou administrador precise determinar se o compartilhamento de arquivo e impressora está permitido em um sistema. Isso pode ser feito com INetFWPolicy2::IsRuleGroupCurrentlyEnabled. A Figura 4 fornece um exemplo de VBScript que demonstra essa função.
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if

Agora, caso o compartilhamento de arquivo e impressora esteja desativado e você precise ativá-lo, primeiramente é necessário garantir que isso possa ser feito e que não será substituído pela Diretiva de Grupo. Isso é feito com a API INetFWPolicy2::LocalPolicyModifyState. Um esqueleto, que pode ser preenchido com código real, é mostrado aqui:
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Linha de comando e tipos de interface
Nenhum firewall estaria completo sem uma linha de comando apropriada ao gerenciamento. Há um subcontexto em netsh, chamado advfirewall. O contexto advfirewall oferece o acesso de linha de comando a tudo o que é possível fazer na interface gráfica do usuário. Por exemplo, caso você queira implementar o bloqueio de saída na porta 445, é possível executar o seguinte comando em um prompt de comando privilegiado:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
Em seguida, você precisa executar o mesmo comando, substituindo TCP por UDP para completar o bloqueio. A essa altura, você já concluiu a implementação da regra.
Um recurso interessante do firewall é a possibilidade de configurar regras com base no tipo de interface da rede. Lembre-se de que algumas regras podem causar impacto sobre conexões VPN. Desde que o Windows reconheça a interface como sendo VPN, é possível usar esse tipo de regra para isentar o tráfego dessa interface:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Também é possível fazer isso na GUI, mas só após a criação da regra. Em seguida, você precisa clicar com o botão direito do mouse na regra, selecionar Propriedades e clicar na guia Avançado. Lá você encontra uma seção Tipos de Interface na qual é possível selecionar os tipos de interface corretos.

Filtragem de saída
A ausência da filtragem de saída no firewall do Windows XP SP2 era considerada uma das principais provas de que o firewall interno não era adequado à segurança. Talvez haja milhares de artigos escritos dizendo que a insegurança do firewall do Windows XP SP2 se deve à ausência da filtragem de saída. Isso apesar do fato de nenhum firewall no Windows XP poder fornecer com segurança a filtragem de saída.
A funcionalidade fundamental que transforma a filtragem de saída em um recurso de segurança útil rapidamente – ou ferramenta de imposição da diretiva, como usava anteriormente – simplesmente não existe no Windows XP. Mas ela existe no Windows Vista. Por isso, é mais do que lógico que o novo firewall use esse recurso. Por padrão, grande parte do tráfego de entrada é bloqueada e a maior parte do tráfego de saída, permitida.
Por padrão, a filtragem de saída no novo firewall do Windows Vista só bloqueia o tráfego desnecessário dos serviços. Isso é realmente tudo o que se pode fazer para fornecer proteção contra um comprometimento no host que ofereça os filtros de saída, e fazer isso no Windows XP seria inútil.
Os serviços no Windows Vista podem ser executados com um token altamente restrito. Basicamente, cada serviço tem seu próprio SID (identificador de segurança), exclusivo do serviço. Esse SID de serviço pode ser usado para restringir o acesso a recursos como, por exemplo, portas de rede. Trata-se da mesma funcionalidade que vimos anteriormente quando observamos a restrição do tráfego para usuários. Isso significa que, mesmo que dois serviços possam ser executados como NetworkService, eles não podem gerenciar os processos um do outro, e o firewall pode ser configurado para permitir que apenas um deles se comunique. Caso um que esteja bloqueado seja comprometido, ele não pode seqüestrar o serviço permitido e usar sua porta permitida para se comunicar porque a porta está restringida pelo SID de serviço.
Essa funcionalidade é outro dos recursos de segurança bem interessantes adicionados ao Windows Vista, e o novo firewall a usa para fornecer, de fato, segurança real por meio da filtragem do firewall de saída.
Na verdade, a filtragem do firewall nas SIDs de serviço está habilitada por padrão no novo firewall. No entanto, não há nenhuma GUI para configurá-la. As regras estão predefinidas na chave do Registro HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Porém, você deve tomar muito cuidado com a modificação manual dessa chave, porque não há suporte para isso.

Qual é o nível de segurança que a filtragem de saída pode fornecer?
Uma questão consideravelmente mal compreendida na comunidade de segurança é o nível do valor de segurança efetivamente oferecido pela filtragem de saída. Até agora mencionei dois cenários que fornecem segurança por meio da filtragem de saída, mas ambos dependem da nova funcionalidade do Windows Vista que até então não estava disponível. Apesar disso, existe uma percepção geral de que a filtragem de saída costuma ser boa e que deve ser um fator-chave nas decisões de compra de firewall.
Ironicamente, em muitas organizações, os recursos da filtragem de saída motivavam a decisão de compra e, dessa forma, a filtragem de saída não era usada após a implementação do firewall. Isso está mal orientado e leva a uma perda financeira e de esforço em relação ao grupo de segurança das informações. Isso parece estar mais ligado a um desejo de se sentir bem quanto a fazer algo relacionado à segurança do que propriamente uma análise real de uma ameaça. É muito comum que o desejo desse tipo de "teatro da segurança" motive decisões que deveriam ser tomadas, na verdade, com base em fatos.
Existe um fato bem simples a respeito da filtragem de saída que seus propositores se esquecem de levar em conta. O argumento habitual dos fornecedores de firewall baseado em host é de que, se um sistema for comprometido, independentemente de ser por um worm ou por um usuário mal-intencionado interativo, a filtragem de saída impedirá que o worm continue infectando os demais sistemas ou que o invasor continue se comunicando. E isso não é verdade.
A verdade é que, com tudo sendo igual, a filtragem de saída interromperia alguns malwares históricos. No entanto, se o Windows XP acompanhasse filtragem de saída, seria mais do que provável que os worms que vimos até hoje fossem escritos para desativar ou até mesmo contorná-la.
No Windows XP (e em versões anteriores do Windows), qualquer worm em execução como serviço (e todos os worms mais comuns que surgem em meio à conversação eram executados como serviço) poderia fazer isso. A única razão pela qual não fizeram isso é que praticamente não havia ambientes usando a filtragem de saída e, por isso, era desnecessário desabilitá-la. Em um ataque interativo, o invasor pode contornar filtros de saída como quiser. Caso o invasor tenha a possibilidade de executar código arbitrário, isso é fácil. Mas, se necessário, o invasor também pode seduzir o usuário a contornar os filtros.
O contorno de filtros de firewall baseados em host de saída pode ser feito de várias formas, dependendo do cenário do ataque real. A maneira mais simples de abordar isso é "pedir" a um usuário com muitos privilégios para fazer isso para você. Muitos ambientes continuam executando usuários como administradores. Esses usuários têm o direito de contornar diretivas de segurança a seu modo. Tudo de que o invasor precisa é apresentar ao usuário uma opção entre um benefício de segurança não imediato e, de certa forma, intangível e algo que ele valoriza muito – algo como duendes.
Em muitos casos, o usuário é tão inundado com esses tipos de caixas de diálogo que acaba clicando rapidamente sem saber, de fato, o que está acontecendo. Trata-se do problema número um em relação à filtragem de saída. Considerando a opção entre a segurança e as recompensas suficientemente atraentes, como os duendes, estes sempre ganharão porque a grande maioria das caixas de diálogo que pede aos usuários tomar decisões de segurança é destituída de qualquer informação que os permitisse realmente tomar essa decisão.
Apresentar caixas de diálogo, pedir decisões de segurança, com informações suficientes para fundamentar essa decisão, é muito mais difícil do que parece porque precisaria que o produto de segurança como, por exemplo, o firewall, compreendesse não apenas portas, protocolos e o aplicativo que está fazendo a solicitação, mas também o que a solicitação está realmente tentando fazer e o que isso significa para o usuário. Essas informações são muito difíceis de serem obtidas programaticamente. Por exemplo, o fato de o Microsoft Word estar tentando estabelecer uma conexão de saída não é tão interessante quanto o que o Word está tentando fazer com essa conexão exatamente.
Precisamos reduzir o número de caixas de diálogo sem significado, e não aumentá-lo, e os firewalls com filtragem de saída não ajudam nisso. Para ter uma idéia da última palavra no fornecimento de informações importantes para o usuário, observei a documentação de venda de um dos principais fornecedores de firewall baseado em host. Eles falam da capacidade de filtragem de saída do firewall e da capacidade de aviso. A capacidade de aviso detecta o que o usuário está tentando fazer e dá o aviso apropriado. Ou assim diz a teoria. O texto do folheto estava acompanhado de uma captura de tela que dizia: "O aviso ainda não está disponível para este programa. Escolha um abaixo ou clique em Mais Informações para obter ajuda". Parece que, até mesmo no material de marketing, os fornecedores não conseguem produzir caixas de diálogo informativas.
Como os usuários não têm informações o suficiente para tomar as decisões de segurança certas, caberia ao administrador configurar toda a filtragem de saída porque o usuário final é incapaz disso. Isso aumenta infinitamente a carga do administrador.
Mesmo que o usuário clique em "Não. Lembre-me mais tarde" quando perguntado pelo firewall, o malware poderia invadir normalmente o firewall. Desde que o usuário que está executando o código mal-intencionado consiga abrir conexões de saída em alguma porta, o código pode simplesmente usar essa porta. Por isso, qualquer processo pode acumular em um processo existente. Isso é permitido em sistemas operacionais de nível inferior. A partir do Windows Vista, os processos podem ser tranqüilamente restringidos, e é por isso que os serviços, aqueles restritos por padrão, são bloqueados usando os filtros de saída por padrão.
Infelizmente, a maioria das pessoas acha que a filtragem de firewall baseado em host de saída impedirá que um ativo comprometido ataque os demais. Isso não é possível. Implantar medidas protetoras em um ativo comprometido e pedir para que ele não comprometa nenhum outro simplesmente não funciona. A proteção pertence ao ativo que você está tentando proteger, e não do que você tentando se proteger! É improvável que pedir para que os maus elementos não roubem nada depois que eles já entraram na sua causa seja algo eficiente quanto impedir que eles invadam a casa antes.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele possui PhD em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP Microsoft em segurança corporativa. Seu livro mais recente é Windows Server 2008 Security Resource Kit.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução parcial ou completa sem autorização..
Page view tracker