Firewall Baseado no Host e Lista de Permissões de Aplicativos

Um firewall de rede fica no perímetro e filtra o tráfego entre segmentos de rede. Um firewall baseado em host é executado no endpoint individual e filtra o tráfego de entrada e saída dessa máquina específica. Os firewalls baseados em host oferecem defesa em profundidade: mesmo que um invasor contorne o firewall de rede (por meio de uma VPN, de um usuário interno comprometido ou de movimentação lateral a partir de outro host infectado), o firewall do host impõe as regras de tráfego local. Eles são especialmente importantes para laptops que saem do perímetro corporativo e se conectam a redes não confiáveis.

O Windows Defender Firewall (WDF) é o firewall de host integrado a todas as versões modernas do Windows. Ele oferece suporte a três perfis: Domínio (conectado ao domínio corporativo — normalmente mais permissivo), Privado (rede doméstica confiável) e Público (redes não confiáveis — o mais restritivo). As regras do WDF podem filtrar por porta, protocolo, caminho da aplicação, IP remoto e identidade do usuário. O snap-in do Windows Defender Firewall com Segurança Avançada (WFAS) para MMC e a Política de Grupo permitem o gerenciamento corporativo centralizado das regras de firewall em todas as máquinas ingressadas no domínio.

Os firewalls de host do Linux usam a estrutura de kernel Netfilter, configurável por meio de iptables (legado, mas ainda amplamente utilizado) ou do moderno nftables. As regras são organizadas em cadeias (INPUT, OUTPUT, FORWARD) dentro de tabelas (filter, nat, mangle). A política padrão deve ser DROP, com regras explícitas de ACCEPT para o tráfego necessário — uma postura de negação por padrão. Ferramentas de nível mais alto, como ufw (Ubuntu) e firewalld (RHEL/CentOS), oferecem interfaces mais amigáveis, mas continuam usando o Netfilter internamente.

Os firewalls baseados em host podem impor regras na camada de aplicação, filtrando o tráfego pela aplicação que o gerou, e não apenas pela porta. O Windows Defender Firewall oferece suporte a regras baseadas em aplicações: permite que C:\Program Files\MyApp\app.exe faça conexões de saída, enquanto bloqueia todo o restante na mesma porta. Isso impede que malwares sequestrem portas permitidas fingindo ser uma aplicação confiável. As regras da camada de aplicação são significativamente mais eficazes do que as regras baseadas apenas em portas, que podem ser contornadas vinculando o malware a portas comuns, como a 443.

O allowlisting de aplicações (anteriormente chamado de whitelisting) é um controle de segurança que permite a execução somente de aplicações explicitamente aprovadas em um endpoint. Qualquer executável que não esteja na lista de permissões será bloqueado, independentemente de ser malware ou simplesmente um software não aprovado. Essa é uma defesa poderosa contra malware, pois até mesmo malwares novos e de dia zero são bloqueados se não estiverem na lista aprovada. O desafio é operacional: gerenciar a lista de permissões em ambientes grandes e dinâmicos exige um processo maduro de gerenciamento de mudanças e gera um volume significativo de chamados de suporte quando é mal ajustado.

O AppLocker é o recurso integrado de controle de aplicações do Windows, disponível nas edições Enterprise e Education. Ele filtra a execução por: caminho (bloqueia executáveis de %TEMP% ou de diretórios graváveis pelo usuário), hash do arquivo (permite apenas hashes conhecidos e confiáveis) ou publisher (permite software assinado pela Microsoft ou pela Adobe). As políticas do AppLocker são implantadas por meio da Política de Grupo e registradas no Log de Eventos do Windows (ID de Evento 8003 = bloqueado). Executar primeiro o AppLocker no Modo de auditoria — registrando os bloqueios sem impô-los — permite que as equipes ajustem a lista de permissões antes do início da aplicação.

O WDAC é o sucessor mais poderoso do AppLocker, aplicado no nível do kernel, e não no espaço do usuário. Diferentemente do AppLocker, o WDAC não pode ser contornado por invasores com direitos de administrador local, o que o torna o controle preferido em ambientes de alta segurança. As políticas do WDAC são escritas em XML e convertidas em arquivos de política binários, implantados por meio do MDM (Intune) ou da Política de Grupo. O WDAC também permite a integração com o Intelligent Security Graph (ISG), que usa o serviço de reputação na nuvem da Microsoft para permitir automaticamente softwares com reputação confiável, reduzindo a carga operacional de organizar manualmente a lista de permissões.

O allowlisting é poderoso, mas exige muito operacionalmente. Desafios comuns: LOLBins (binários Living-Off-the-Land) — os invasores usam ferramentas do sistema Windows, como PowerShell, wscript.exe e mshta.exe, que normalmente estão em todas as listas de permissões; o allowlisting deve restringir como essas ferramentas são invocadas, e não apenas se podem ser executadas. Linguagens de script (PowerShell, Python) geralmente estão na lista de permissões, mas podem executar código malicioso. Falsos positivos — softwares legítimos bloqueados pela lista de permissões — geram chamados ao suporte e pressão para enfraquecer os controles. Programas maduros de allowlisting lidam com LOLBins por meio de políticas adicionais de modo de linguagem restrita.

O allowlisting permite somente itens explicitamente aprovados e bloqueia todo o restante — uma postura de segurança mais forte. O denylisting (blacklisting) bloqueia itens explicitamente conhecidos como maliciosos e permite todo o restante — o modelo tradicional de antivírus. O denylisting falha contra ameaças desconhecidas; o allowlisting falha contra LOLBins e entradas de permissão excessivamente amplas. A maioria dos programas de segurança maduros usa o allowlisting como controle principal em sistemas críticos, enquanto utiliza detecção comportamental (EDR) para identificar o uso indevido de aplicações permitidas. Para sistemas menos críticos, uma lista de negação bem ajustada, com monitoramento comportamental, pode ser aceitável.

Firewalls baseados em host e allowlisting de aplicações são controles complementares e em camadas. A lista de permissões impede a execução de código não autorizado; o firewall impede conexões de rede não autorizadas originadas por código autorizado, mas comprometido. Juntos, eles implementam os princípios do menor privilégio nas camadas de aplicação e de rede do endpoint. A adição do EDR como terceira camada cria uma estrutura de defesa em profundidade na qual cada controle identifica o que os outros podem não detectar, aumentando significativamente o custo e a complexidade de ataques bem-sucedidos contra endpoints.

Os firewalls baseados em host só são tão valiosos quanto os registros que geram. Ative o registro de conexões bloqueadas para capturar tentativas de ataque e violações de políticas. Ative o registro de conexões permitidas em regras sensíveis (como as que permitem ferramentas administrativas) para manter uma trilha de auditoria. Encaminhe os registros do firewall para o SIEM para correlação — um padrão de conexões de saída bloqueadas de um único host pode indicar que um malware está tentando realizar chamadas de retorno C2. No Windows, os registros do firewall são gravados por padrão em %systemroot%\System32\LogFiles\Firewall\pfirewall.log e devem ser encaminhados por meio do Windows Event Forwarding (WEF) ou de um agente de registros.

Teste sua compreensão dos conceitos de CompTIA Segurança+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu: firewalls baseados em host (Windows Defender Firewall, iptables) filtram o tráfego por endpoint, com uma postura de negação por padrão e regras com escopo de aplicação; o allowlisting de aplicações (AppLocker, WDAC) bloqueia a execução de executáveis não autorizados, inclusive malwares; e a combinação de firewall, allowlisting e EDR cria uma defesa em profundidade que aumenta significativamente o custo do ataque. A seguir, exploraremos a autenticação de e-mail: SPF, DKIM e DMARC.