O que são as regras de saída do Windows Firewall?
Um piloto com bloqueio por defeito começa com um conjunto definido de computadores e uma lista documentada das ligações necessárias. Depois, testa se essas ligações continuam a funcionar sob a política pretendida. As regras de saída do Windows Firewall controlam as ligações que saem de um computador Windows. A ação de saída por defeito de um perfil determina o que acontece quando nenhuma regra aplicável permite ou bloqueia esse tráfego.
Esta é uma opção de reforço de segurança com custos operacionais. A Microsoft recomenda permitir o tráfego de saída por defeito na maioria das implementações e considera o bloqueio por defeito para certos ambientes de elevada segurança. Por isso, um resultado relativo à ação por defeito recolhida dá início a uma análise; não estabelece uma obrigação universal de bloquear o tráfego de saída em todo o domínio. Consulte as orientações da Microsoft sobre regras do Windows Firewall.
A questão prática é saber se a sua organização consegue manter uma lista de permissões útil para os computadores escolhidos. Antes de alterar a ação por defeito, defina quem é responsável pelas mudanças, quais as aplicações que precisam de comunicar e como recuperar dependências que deixem de funcionar. Uma política que interrompa atualizações ou a gestão remota sem uma via de recuperação pode comprometer o objetivo do exercício.
Como funciona: a ação por defeito de um perfil difere de uma regra de bloqueio
Os perfis Domain, Private e Public têm configurações separadas. Escolha deliberadamente o perfil do piloto e verifique o perfil utilizado na rede de destino. Uma configuração do perfil Domain não demonstra o que acontece quando o mesmo computador utiliza uma rede Private ou Public.
É necessário distinguir dois modelos diferentes. Com uma ação de saída por defeito definida como Block, uma regra explícita de permissão aplicável pode autorizar o tráfego necessário. Com uma regra explícita de bloqueio abrangente, uma regra de permissão normal em conflito não restabelece esse tráfego: as regras explícitas de bloqueio têm precedência. Uma permissão mais específica não contorna um bloqueio explícito sobreposto. Estes comportamentos de precedência também se aplicam às regras de saída.
Os repositórios de políticas também são relevantes. Uma regra guardada numa GPO de gestão descreve a configuração pretendida. O ActiveStore do destino representa a política atualmente ativa, composta a partir dos repositórios aplicáveis. A combinação de regras locais pode afetar quais as exceções que participam. Analise as configurações reais dessa combinação e as origens das regras, em vez de presumir que uma exceção criada localmente será utilizada. O guia de gestão pela linha de comandos da Microsoft documenta operações locais e em GPO.
Separe as restrições de autenticação das restrições de conectividade. O nosso guia para bloquear NTLM enviado por sistemas Tier 0 aborda a restrição de um mecanismo de autenticação envolvido em coerção e relay. Essa decisão não define uma lista de permissões de firewall para aplicações e destinos. Da mesma forma, uma ação de saída por defeito da firewall não demonstra que a autenticação NTLM está desativada.
Deteção: comparar os dados de GPO recolhidos com o destino
Registe o computador, o contexto de rede, o âmbito pretendido da política e a hora da recolha. Execute separadamente os seguintes comandos de leitura em PowerShell num destino Windows representativo. São exemplos baseados na documentação, não medições realizadas para este artigo.
Passo 1: ler as configurações dos perfis ativos
A Microsoft documenta Get-NetFirewallProfile com ActiveStore:
Get-NetFirewallProfile -PolicyStore ActiveStore
Inspecione Name, Enabled e DefaultOutboundAction para cada perfil, juntamente com as configurações de combinação de regras locais e de registo. Preserve a saída devolvida. Confirme qual o perfil de rede que o piloto realmente utiliza. Um valor Block num perfil inativo não constitui prova suficiente de que o fluxo testado foi filtrado.
Compare o resultado de Domain com o valor WindowsFirewall/DomainProfile/DefaultOutboundAction da GPO recolhido de Registry.pol. Na representação do detetor, 0 significa Allow e 1 significa Block. Quando o valor da GPO está ausente ou diverge do destino, investigue a aplicação da política e as fontes de configuração concorrentes. Não substitua o resultado ativo do computador pelo valor escolhido pelo collector.
Passo 2: inspecionar as regras de saída e as suas origens
Utilize a referência de Get-NetFirewallRule para obter as regras de saída da política ativa e identificar os repositórios de origem:
Get-NetFirewallRule -Direction Outbound -PolicyStore ActiveStore -TracePolicyStore
Analise o estado de ativação, a ação, o perfil, a origem e os filtros associados de aplicação, serviço, endereço e porta. Os objetos das regras, por si só, não mostram integralmente todos os filtros associados. Inspecione esses detalhes em Windows Firewall with Advanced Security ou através dos cmdlets de filtro NetSecurity correspondentes. Identifique regras de bloqueio sobrepostas e permissões demasiado abrangentes antes de interpretar um teste de conectividade.
O nosso guia de segurança de GPO com quatro verificações utiliza o mesmo método de verificação: comparar a intenção da política, os computadores que a recebem e a proteção efetivamente utilizada. As suas verificações de LLMNR, WSUS, LSA e UNC não demonstram cobertura da firewall de saída. Aplique aqui o método com provas específicas da firewall no destino.
Passo 3: observar o tráfego necessário e o rejeitado
Leia o LogFileName configurado no perfil, em vez de presumir que todos os computadores utilizam o mesmo caminho. O guia de linha de comandos apresenta %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log. A referência de Set-NetFirewallProfile documenta o registo de pacotes aceites e descartados. Relacione as entradas conservadas com a operação da aplicação, a hora, o protocolo e os extremos da ligação que está a testar.
Num piloto de laboratório isolado e gerido localmente, este comando ativa ambas as opções de registo para Domain:
Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True
Nos computadores geridos, configure o registo na política responsável e verifique-o no ActiveStore. As alterações de registo são independentes da ação de saída por defeito. Registe as configurações anteriores e planeie a retenção para manter disponíveis as provas de diagnóstico. Um pacote descartado é um ponto de partida para investigação, não uma prova de malware. A ausência de entradas num registo não prova que todos os caminhos das aplicações estão autorizados.
Correção: planear um piloto delimitado com bloqueio por defeito (Remediation)
Passo 1: decidir se o bloqueio por defeito se adequa ao conjunto de computadores
Documente a justificação operacional e de segurança do piloto, os computadores escolhidos e o limite do perfil Domain. Selecione um conjunto gerível, com responsáveis pelas aplicações disponíveis para o testar. Identifique janelas de manutenção, responsabilidades de monitorização e uma via de recuperação independente. Decida quais as provas que permitirão alargar o piloto e qual a falha que exigirá rollback.
Se o inventário de dependências estiver incompleto ou ninguém o puder manter, registe essa limitação e resolva-a antes de aplicar o bloqueio. O objetivo é uma política de conectividade sustentável. Encerrar um resultado de configuração alterando uma ação por defeito em todo o domínio, sem compreender o seu efeito, não é um critério de sucesso útil.
Passo 2: inventariar aplicações e dependências
Para cada aplicação e serviço, registe o executável ou a identidade do serviço, os destinos pretendidos, o protocolo, as portas de destino, o horário de funcionamento e o responsável. Inclua explicitamente a resolução DNS, a obtenção de atualizações, os agentes de gestão, a administração remota e as ferramentas de recuperação como itens de análise. Inventarie tanto as operações habituais como as tarefas de manutenção pouco frequentes. Uma sessão interativa bem-sucedida não testa uma atualização ou cópia de segurança agendada.
Utilize requisitos dos fornecedores e operações legítimas observadas para construir a lista. Distinga os destinos exigidos diretamente pela aplicação da infraestrutura de apoio, como um proxy ou um resolvedor. Quando os extremos das ligações mudam ao longo do tempo, documente como será mantida a lista de permissões. Não deduza um mapa completo de dependências a partir de uma captura breve de pacotes, nem aprove automaticamente todas as ligações observadas.
Passo 3: preparar regras de permissão documentadas
Crie as exceções necessárias antes de ativar o bloqueio por defeito. Associe a cada regra um responsável, uma finalidade, um perfil e uma decisão de análise. Verifique se as regras chegam ao piloto através do repositório de políticas pretendido e resolva os conflitos com bloqueios explícitos. Inspecione a combinação de regras locais para que as regras instaladas pelas aplicações e as exceções criadas pelos administradores recebam um tratamento deliberado.
A regra ilustrativa seguinte utiliza os parâmetros documentados em New-NetFirewallRule. O caminho, o endereço, a porta, o domínio e a GPO são exemplos a substituir por valores verificados do inventário. Esta regra não deve ser implementada sem alterações:
New-NetFirewallRule -DisplayName "Pilot application to approved service" -Direction Outbound -Action Allow -Profile Domain -Program "C:\Program Files\Example\client.exe" -Protocol TCP -RemoteAddress 192.0.2.10 -RemotePort 443 -PolicyStore "corp.contoso.com\Outbound Pilot"
Uma única exceção de exemplo não constitui um inventário das dependências de uma aplicação. Adicione apenas as regras justificadas pela carga de trabalho real, incluindo os seus serviços de apoio. Analise também as permissões abrangentes existentes: o bloqueio por defeito tem valor limitado se uma exceção geral continuar a permitir as ligações que pretendia restringir.
Passo 4: alterar apenas o âmbito escolhido do perfil Domain
Para a GPO do piloto de exemplo, os parâmetros documentados de Set-NetFirewallProfile podem expressar a ação por defeito selecionada:
Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Block -PolicyStore "corp.contoso.com\Outbound Pilot"
Confirme que esta GPO se aplica apenas ao conjunto selecionado antes de a alterar. Preserve a configuração anterior e mantenha a firewall ativada. Após a aplicação da política, repita as consultas de perfis e regras do ActiveStore nos computadores de destino. Um comando de gestão bem-sucedido escreve configuração; não demonstra que todos os destinos pretendidos a aplicaram.
Passo 5: medir os fluxos e ensaiar o rollback
Teste cada operação registada sob o perfil Domain ativo. Verifique o comportamento das aplicações, a resolução de nomes, as verificações de atualizações, o acesso de gestão e o acesso de recuperação. Compare as falhas com o tráfego descartado e os detalhes das regras. Quando uma ligação é necessária, documente a sua finalidade antes de adicionar ou corrigir a exceção adequada. Depois, volte a testar a operação original.
Defina um teste controlado para tráfego que a política deve rejeitar, utilizando um destino de teste e uma carga de trabalho aprovados. Registe o resultado esperado e as provas reais no destino. Evite interpretar uma rejeição bem-sucedida como prova de que todas as saídas indesejadas estão bloqueadas. Mantenha juntos os registos de operações permitidas e rejeitadas para que os revisores possam avaliar a intenção de segurança e a compatibilidade.
Se a ação por defeito anterior registada para a GPO de exemplo era Allow, o comando de rollback é:
Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Allow -PolicyStore "corp.contoso.com\Outbound Pilot"
Restaure o estado real anterior da política quando este era diferente, incluindo uma configuração não definida quando aplicável. Analise separadamente as regras do piloto e as alterações de registo. Um bloqueio explícito que permaneça pode continuar a impedir a conectividade depois de a ação por defeito voltar a Allow. Volte a verificar o ActiveStore e repita a operação de negócio que falhou antes de declarar a recuperação concluída. Alargue o piloto apenas quando o inventário, as responsabilidades, os testes e o registo de rollback sustentarem o próximo conjunto de computadores.
Como a EtcSec deteta esta configuração
A implementação Detect() de etc-collector analisada disponibiliza uma verificação relevante neste contexto: FIREWALL_OUTBOUND_NOT_BLOCKED. Inicializa um resultado de gravidade Low com Count = 0 e procura o inteiro FirewallOutboundAction recolhido. Se a pesquisa devolver nil ou qualquer valor diferente de 1, define Count = 1. Um valor devolvido de 1 mantém Count = 0.
O parser de Registry.pol preenche esse campo apenas a partir de uma chave correspondente a WindowsFirewall e DomainProfile, com o nome de valor DefaultOutboundAction. Os valores dos perfis Private e Public ficam fora desta verificação. A função auxiliar de inteiros procura primeiro um valor não nil em Default Domain Controllers Policy, depois em Default Domain Policy e, finalmente, noutra GPO disponível. A alternativa percorre um mapa Go; não determina a precedência das políticas Windows.
Estes limites são relevantes ao analisar um resultado. A ausência de um valor de GPO recolhido desencadeia a verificação sem medir a ação por defeito efetiva ou a aplicação real num computador. Count = 1 não conta extremos expostos nem demonstra tráfego de comando e controlo. Count = 0 não valida a ativação da firewall, as regras de permissão necessárias, os conflitos com bloqueios explícitos, as exceções locais ou o funcionamento bem-sucedido do piloto.
Utilize este sinal para iniciar a investigação delimitada descrita acima. Junte à análise o perfil ativo do destino, as regras efetivas, os testes das aplicações e as provas de rollback. Decida se o bloqueio por defeito é adequado para esse conjunto de computadores e esclareça a questão de configuração com as provas obtidas, em vez de utilizar apenas a pesquisa agregada de GPO.
Explore as paginas de identidade que sustentam este tema