Hardening de Servidores Windows: Guia Prático

Artigo pronto. HTML abaixo, só seções, ~1300 palavras. ```html

Por que o hardening é a base da segurança de servidores

Um Windows Server recém-instalado não é um servidor seguro. A configuração padrão prioriza compatibilidade e facilidade de uso: serviços que você nunca vai usar ficam habilitados, protocolos criados nos anos 90 continuam ativos e permissões são mais abertas do que deveriam. Cada um desses itens é uma porta potencial de entrada. Hardening é o processo sistemático de fechar essas portas — reduzir a superfície de ataque até que reste apenas o estritamente necessário para o servidor cumprir sua função.

O impacto é mensurável. A grande maioria dos incidentes com ransomware em empresas brasileiras não começa com uma vulnerabilidade zero-day sofisticada, mas com o básico mal feito: RDP exposto à internet, SMBv1 habilitado, contas administrativas sem controle e ausência de auditoria. Um atacante que encontra um servidor sem hardening tem trabalho fácil; um servidor endurecido força o invasor a fazer barulho — e barulho é o que os sistemas de detecção precisam para agir.

Este guia apresenta um checklist prático dividido em cinco frentes: serviços e funções, políticas de grupo (GPOs), protocolos legados, acesso remoto via RDP e auditoria. Ele se aplica ao Windows Server 2016, 2019, 2022 e 2025, com ajustes pontuais entre versões.

Serviços e funções: desative o que não usa

O primeiro princípio do hardening é o da funcionalidade mínima: cada servidor deve rodar apenas os serviços e funções necessários ao seu papel. Um servidor de arquivos não precisa de IIS; um controlador de domínio não precisa de serviço de impressão. Cada função instalada carrega binários, portas abertas e vetores de ataque próprios — o Print Spooler, por exemplo, foi o vetor da vulnerabilidade PrintNightmare, que permitiu execução remota de código em milhares de servidores que nem sequer eram servidores de impressão.

Comece com um inventário: execute Get-WindowsFeature | Where-Object Installed no PowerShell e questione cada item da lista. Em seguida, revise os serviços em execução e seu tipo de inicialização. O checklist mínimo inclui:

• Print Spooler: desative em todos os servidores que não gerenciam impressão, especialmente controladores de domínio;
• Fax, Xbox Services e Telemetria não essencial: sem função em ambiente de servidor;
• Remote Registry: desative se não houver ferramenta de gestão que dependa dele;
• SNMP v1/v2: se o monitoramento exigir SNMP, prefira a versão 3 com autenticação;
• Web Client (WebDAV): raramente necessário e frequentemente abusado em ataques de coerção de autenticação.

Considere também o Server Core para novos servidores de infraestrutura. Sem interface gráfica, o Server Core elimina navegador, componentes de mídia e dezenas de bibliotecas — menos código instalado significa menos patches e menos superfície exposta. Para funções como Active Directory, DNS, DHCP e Hyper-V, a administração remota via PowerShell e Windows Admin Center cobre praticamente todas as necessidades do dia a dia.

GPOs e baselines: padronize a segurança em escala

Configurar servidor por servidor não escala e não se sustenta: alguém sempre esquece um item, e configurações manuais sofrem "drift" com o tempo. As Group Policy Objects (GPOs) resolvem os dois problemas — aplicam a configuração de forma centralizada e a reaplicam automaticamente, revertendo alterações locais indevidas.

Não é preciso começar do zero. A Microsoft publica os Security Baselines dentro do Security Compliance Toolkit: conjuntos de GPOs prontos, revisados a cada versão do Windows Server, cobrindo centenas de configurações de segurança com valores recomendados. Importe o baseline correspondente à sua versão, compare com o ambiente atual usando o Policy Analyzer e aplique primeiro em um grupo piloto antes de expandir para produção. Quem precisa atender requisitos regulatórios pode usar como referência os benchmarks do CIS (Center for Internet Security), mais rigorosos e organizados em níveis de aplicabilidade.

Alguns pontos merecem atenção especial dentro das políticas:

• Política de senhas e bloqueio de conta: senhas longas (14+ caracteres), bloqueio após tentativas falhas e, idealmente, proteção contra senhas vazadas;
• LAPS (Local Administrator Password Solution): senha de administrador local única e rotacionada automaticamente em cada servidor — elimina o movimento lateral por senha local compartilhada;
• User Rights Assignment: restrinja "Log on locally", "Log on through Remote Desktop Services" e "Access this computer from the network" a grupos específicos;
• PowerShell: habilite Script Block Logging e Module Logging — visibilidade essencial, já que a maioria dos ataques modernos usa PowerShell;
• SMB Signing e LDAP Signing: obrigatórios para mitigar ataques de relay de autenticação.

Baseline sem gestão de exceções vira baseline abandonado. Documente cada desvio — qual servidor, qual configuração, por quê e até quando — e revise a lista trimestralmente. Exceção sem prazo de validade é vulnerabilidade permanente com carimbo oficial.

Protocolos legados: o elo mais fraco da cadeia

Protocolos antigos permanecem habilitados por décadas em nome da compatibilidade, e são o caminho preferido dos atacantes justamente por isso. O caso mais emblemático é o SMBv1: protocolo de 1990, sem as proteções modernas de integridade, foi o vetor do WannaCry e do NotPetya via exploit EternalBlue. Não há justificativa para mantê-lo em 2026 — remova com Uninstall-WindowsFeature FS-SMB1 e trate qualquer dependência remanescente (multifuncionais antigas, sistemas legados) como projeto de substituição urgente.

A lista de legados a eliminar ou restringir vai além do SMBv1:

• LLMNR e NetBIOS over TCP/IP: protocolos de resolução de nomes que respondem a qualquer máquina na rede — base dos ataques de envenenamento com ferramentas como o Responder, que capturam hashes de credenciais. Desative ambos via GPO e DHCP;
• NTLMv1 e LM: algoritmos de autenticação quebrados. Configure a política "LAN Manager authentication level" para "Send NTLMv2 response only. Refuse LM & NTLM" e inicie a auditoria de uso de NTLM visando a migração completa para Kerberos;
• TLS 1.0 e 1.1 / SSL 3.0: desabilite via registro ou GPO, mantendo apenas TLS 1.2 e 1.3, com suítes de cifra fortes;
• WDigest: confirme que está desabilitado — quando ativo, armazena senhas em texto claro na memória do LSASS.

Antes de desativar qualquer protocolo em produção, audite o uso real. O Event Log registra autenticações NTLM e conexões SMBv1 quando a auditoria está habilitada; duas a quatro semanas de coleta revelam quais sistemas ainda dependem do legado e evitam que o hardening derrube uma aplicação crítica de madrugada.

RDP: acesso remoto sem virar porta de entrada

O RDP é simultaneamente indispensável para administração e o vetor de intrusão mais explorado em pequenas e médias empresas. Servidores com a porta 3389 exposta à internet são escaneados e atacados por força bruta em questão de minutos após ficarem online — e credencial RDP válida é mercadoria vendida em massa em fóruns criminosos.

A regra número um é simples: RDP nunca deve estar exposto diretamente à internet. Mudar a porta padrão não resolve — scanners identificam o serviço em qualquer porta. As camadas corretas de proteção são:

1. Acesso apenas via VPN ou Remote Desktop Gateway: o RDP fica acessível somente de dentro da rede ou através de um gateway com HTTPS e autenticação forte;
2. MFA obrigatório: autenticação multifator no acesso VPN ou no gateway — credencial vazada sem segundo fator não abre porta alguma;
3. NLA (Network Level Authentication) habilitado: exige autenticação antes de estabelecer a sessão, bloqueando ataques que exploram a tela de login;
4. Restrição por grupo e por origem: apenas contas administrativas nomeadas no grupo de acesso remoto, com firewall limitando as origens permitidas;
5. Bloqueio de conta e monitoramento: lockout após tentativas falhas e alerta sobre os eventos 4625 (falha de logon) em volume anômalo.

Para ambientes com muitos administradores, considere o modelo de jump server: um servidor de salto endurecido e monitorado por onde passam todos os acessos administrativos, simplificando auditoria e resposta a incidentes.

Auditoria contínua: hardening não é projeto, é processo

Endurecer o servidor uma vez e nunca mais revisar é quase tão arriscado quanto não endurecer. Atualizações instalam componentes novos, administradores criam exceções temporárias que viram permanentes, e novas técnicas de ataque tornam obsoletas configurações que eram adequadas. O hardening precisa de três mecanismos contínuos: auditoria de eventos, verificação de conformidade e revisão periódica do baseline.

Na auditoria de eventos, configure a Advanced Audit Policy para registrar, no mínimo: logons e falhas de logon (4624/4625), uso de privilégios especiais (4672), alterações em grupos privilegiados (4728/4732), criação de serviços e tarefas agendadas (7045/4698) e limpeza de log (1102) — este último quase sempre indica invasor cobrindo rastros. Centralize os logs em um SIEM ou coletor dedicado: log que só existe no servidor comprometido é log que o atacante apaga. Na verificação de conformidade, ferramentas como o Policy Analyzer e scanners de configuração comparam o estado real dos servidores com o baseline definido e denunciam o drift antes que ele vire incidente.

Manter esse ciclo rodando — baseline atualizado, exceções sob controle, logs monitorados e resposta rápida a desvios — exige rotina e equipe dedicada, algo que nem toda empresa consegue sustentar internamente. É exatamente esse o papel de um parceiro de TI. A Duk Informática & Cloud aplica e mantém baselines de segurança em ambientes Windows Server há mais de 18 anos, com monitoramento contínuo, gestão de patches e auditoria para mais de 550 empresas atendidas. Como Microsoft Gold Partner, com suporte 24/7 e data center próprio em Alphaville, a Duk transforma o checklist deste artigo em prática permanente — do diagnóstico inicial da superfície de ataque à operação diária segura dos seus servidores.

``` ~1310 palavras, 6 seções h2, ul/ol/blockquote presentes, Duk na última seção.