O firewall incluído no Windows está activado desde a primeira inicialização, mas raramente passa disso: a maioria das PMEs nunca abre a consola de gestão, e as regras ficam por conta das aplicações. O resultado é um firewall que responde, mas não define: tudo o que sai do dispositivo circula sem controlo, e a política real de rede fica nas caixas do fabricante. Este artigo mostra o que gestão séria do Windows Defender Firewall significa em Windows 11 e Windows Server: os três perfis de rede, o controlo de saída que quase ninguém activa, as regras específicas por aplicação e porta, a aplicação automática por GPO ou Intune, e o log para o troubleshooting — tudo com as ferramentas que a instalação já traz.

⚠ Antes de criar regras: testa primeiro num dispositivo de laboratório e num grupo piloto de utilizadores. Uma regra de saída mal medida (ex. um Block demasiado amplo) arranca aplicações em toda a rede — começa por Allow específico e só bloqueia o geral depois de medir.

Os três perfis de rede

O firewall aplica conjuntos de regras distintos conforme a rede em que o dispositivo se ligou — os três perfis do Windows:

  • Domínio — aplicado automaticamente a dispositivos associados ao domínio, quando o controlador de domínio é detectado. Não se escolhe à mão: é o perfil que governa a rede da empresa.
  • Privado — para redes identificadas como domésticas ou de escritório sem domínio (uma rede para PME a operar servidor Windows sem AD fica aqui). O administrador marca a rede como privada à primeira ligação — o Get-NetConnectionProfile confirma em que perfil está cada interface.
  • Público — o mais restritivo, e o que arranca por omissão em qualquer rede não identificada: cafés, hotéis, o Wi-Fi de uma feira. É o perfil por omissão de qualquer rede nova que o Windows não identifique.

O mesmo portátil pode estar no perfil Domínio no escritório, Privado em casa e Público na rua — e as regras aplicam-se apenas ao perfil activo em cada momento. Regras escritas sem indicar o perfil aplicam-se aos três, o que raramente é o que se deseja em produção: escreve o perfil em cada regra que cria.

Como funciona por omissão

O comportamento base do firewall: o tráfego que entra é bloqueado, a não ser que corresponda a uma regra ou tenha sido solicitado — e o que sai é autorizado, salvo regra em contrário. Em terminologia Windows: o tráfego de entrada é bloqueado por omissão (com a excepção do tráfego pedido pelo próprio sistema, como uma resposta HTTP), e o de saída é permitido.

É exactamente isso que torna o firewall “invisível” nas PMEs: as aplicações funcionam para fora, o bloqueio de entrada evita os piores cenários, e ninguém sente falta do controlo de saída — até ao dia em que uma app desconhecida exfiltre dados para um destino externo sem que nenhuma regra a limitasse.

A consola WFAS: regras específicas

A consola de gestão completa — Windows Defender Firewall with Advanced Security (wf.msc) — é a interface de referência para as regras com critérios compostos. Cada regra pode combinar programa, portas de origem/destino, protocolo (TCP/UDP ou número personalizado), endereços IP específicos de origem/destino, perfil de rede e até contas de utilizador ou grupos (em Domain/Private) — uma regra de saída que autorize apenas o executável do ERP a falar só com o servidor da aplicação, na porta e via perfil Domínio, desenha-se aqui:

# Abrir a consola:
wf.msc
# New Rule → Program → caminho do executável (ex. C:\App\erp.exe)
#   → Action: Allow → Protocol: TCP → Remote port: 1433
#   → Profile: Domain → Name: ERP → SQL Server (produção)

A precedência de regras: block ganha a allow (block sobrepõe), e regras explicitamente definidas valem as default — por isso uma exceção bem escrita vale mesmo quando a política global bloqueia tudo.

O controlo de saída que ninguém activa

A mudança de mentalidade está no controlo de saída: em vez de só bloquear o que entra, decide-se também o que pode sair — que aplicações falam com que destinos, em que portas. Tal como na entrada, o primeiro passo não é escrever regras — é mudar a acção por omissão do perfil. O comando Set-NetFirewallProfile -DefaultOutboundAction Block -Profile Domain inverte o comportamento — passa de “tudo sai” para “nada sai sem regra” — e é o modelo que a Microsoft descreve para ambientes de alta segurança, com um inventário das aplicações de trabalho como pré-requisito. Sem esse inventário, a alternativa mais leve é restringir por destino: blocks de portas que nenhuma aplicação de trabalho usa para falar com a Internet.

  • Começa pelo log, não pelos bloqueios: activa o log de pacotes descartados e permitidos (ver secção de logging), deixa correr alguns dias e identifica as conexões de saída que não reconheces.
  • Ou bloqueia por omissão, ou bloqueia restrito: com DefaultOutboundAction Block, a saída passa a trabalhar por excepção — cada aplicação de trabalho precisa da sua regra Allow. Sem omissão a Block, só escreve blocks com destino bem definido (uma porta que ninguém de trabalho usa) — um Block amplo prevalece sobre qualquer Allow, por mais específico que este seja.
  • O que procurar no log: conexões de saída para portas que a tua rede não usa — SMTP (25/465/587) fora do servidor de e-mail, RDP (3389) para destinos fora da rede — são típicas de bots de spam e de ferramentas de ataque que tentam ligações directas fora do proxy.

Risco: uma política de saída aplicada por GPO a toda a rede, sem piloto, é a forma mais rápida de receber dezenas de telefonemas de utilizadores na segunda-feira de manhã. Testa num OU de laboratório primeiro — e só alarga depois de confirmar que nenhuma aplicação de trabalho tenha ficado partida.

Regras em PowerShell

O PowerShell é a forma de automatizar e de rever as regras existentes, e os cmdlets são directos — a criação da regra do ERP da secção anterior:

New-NetFirewallRule -DisplayName "ERP - SQL Server (Produção)" `
  -Direction Outbound -Action Allow -Program "C:\App\erp.exe" `
  -Protocol TCP -RemotePort 1433 -Profile Domain

# A alternativa de alta segurança — saída por omissão a Block no perfil de Domínio:\nSet-NetFirewallProfile -Profile Domain -DefaultOutboundAction Block\n# As excepções — cada aplicação de trabalho, a sua regra Allow:\nNew-NetFirewallRule -DisplayName "ERP - SQL Server (Produção)" `\n  -Direction Outbound -Action Allow -Program "C:\\App\\erp.exe" `\n  -Protocol TCP -RemotePort 1433 -Profile Domain\nNew-NetFirewallRule -DisplayName "SMTP - servidor de e-mail" `\n  -Direction Outbound -Action Allow -Program "C:\\Mail\\smtp.exe" `\n  -Protocol TCP -RemotePort 25,465,587 -Profile Domain

A inspecção também é imediata: Get-NetFirewallRule | Where-Object Enabled -eq True lista as activas, e Get-NetFirewallPortFilter (com pipeline) mostra as portas por regra. Desactivar/reverter é Set-NetFirewallRule -Enabled False, e o export da configuração completa (GPO ou local) é netsh advfirewall export:

# Exportar a política inteira:
netsh advfirewall export "C:\backup\firewall-policy.wfw"
# Listar regras activas de saída:
Get-NetFirewallRule -Direction Outbound -Enabled True | Select DisplayName, Action

Aplicação em escala: GPO e Intune

Num parque com Active Directory, o firewall gere-se por GPO — Configuração do Computador → Políticas → Definições do Windows → Definições de Segurança → Windows Defender Firewall com Segurança Avançada — criando uma política que configura os três perfis (separar por perfil em GPOs distintas é opcional). O detalhe importante: as regras da GPO entram por merge com as locais, a não ser que a política Apply local firewall rules (uma por perfil) esteja desactivada. Nesse caso, apenas as regras da GPO contam, e as locais valem só para dispositivos fora do domínio.

Num parque Intune (ou híbrido Entra), o Firewall CSP é o caminho — o mesmo modelo que a GPO, com perfis de configuração dedicados no Intune admin center (Endpoint security → Firewall). O CSP define o estado de cada perfil, as regras — cada uma como nó próprio (aplicação, protocolo, portas, endereços) — e a opção de merge com regras locais. Para quem já gere ASR e Device Control pelo Intune, o fluxo é o mesmo: um perfil de firewall por tipo de dispositivo, as excepções no seu perfil próprio.

Log e troubleshooting

O log do firewall — desactivo por omissão, tanto para pacotes descartados como permitidos — é a diferença entre adivinhar e saber. Activa-se na consola (Windows Defender Firewall Properties → o perfil → Customize → Logging) ou por PowerShell:

Set-NetFirewallProfile -Profile Domain,Private,Public `
  -LogBlocked $true -LogAllowed $true -LogMaxSizeKilobytes 16384
# O ficheiro por omissão: %systemroot%\system32\LogFiles\Firewall\pfirewall.log

Em cada linha, o log indica a data, acção (DROP ou ALLOW), protocolo, IPs e portas de origem/destino e o PID do processo — os IPs e portas identificam o destino. O nome da aplicação exige cruzar o PID com os processos desse momento (o log não guarda o nome do executável). Para investigação rápida de uma aplicação, o Test-NetConnection e a lista de regras activas (Get-NetFirewallRule -PolicyStore ActiveStore) cobrem o resto.

Erros comuns

  • A aplicação deixa de funcionar a seguir a um Block: uma regra Block prevalece sobre qualquer Allow em conflito — se a política de saída for por omissão a Block, faltou a regra Allow da aplicação. Se for um block restrito, restringe o destino em vez de adicionar allows.
  • A regra existe mas não conta: sem -Profile, a regra vale para os três perfis. Num portátil fora da rede de Domínio, o perfil activo não é o Domínio — define sempre o perfil em cada regra.
  • As regras locais desaparecem depois da GPO: quando não há merge, as locais só contam fora do domínio — decide em política de empresa e escreve as regras nas duas extremidades para o efeito.

Veredicto

O firewall do Windows é mais robusto do que a sua reputação sugere — o problema é que a configuração de origem fica sem gestão activa. Os três perfis evitam o pior, o PowerShell permite o resto: inspecção, regras compostas, e rollback por export. O esforço real está no controlo de saída, que exige um inventário das aplicações de trabalho — o mesmo que uma política ASR já pede: quem fez esse inventário tem metade do caminho feito para o firewall.

Artigos Relacionados

Fontes Oficiais