Como fazer um teste de segurança do que o meu site WordPress expõe?

Por que isso importa

A maioria dos conselhos de segurança fala de botões: ative isto, desative aquilo. Mas um botão diz o que você pediu, não o que aconteceu. Uma camada de cache pode servir uma resposta antiga. Uma regra da CDN pode bloquear um arquivo antes de o WordPress sequer ver a requisição. Um plugin pode reabrir algo que outro fechou. A única resposta honesta para "o que o meu site expõe?" é perguntar a ele do jeito que um estranho perguntaria.

A boa notícia: a lista do que vale verificar no lado do login é curta. Os bots procuram o mesmo punhado de endereços em todo site WordPress:

Nenhum desses é um desastre sozinho. Juntos, eles entregam a um bot uma lista de nomes e duas portas para testá-los. Saber quais estão abertos permite fechá-los na ordem certa: primeiro as portas, depois os nomes.

Erros comuns

• Testar estando conectado. O WordPress mostra mais para usuários conectados. Use uma janela anônima ou o curl.
• Testar a página em cache. Se você acabou de mudar uma configuração, limpe antes o cache de página e o cache da CDN, ou verá a resposta antiga.
• Parar no primeiro sinal verde. Fechar o formulário de login enquanto o XML-RPC continua aberto é a meia-solução mais comum que vemos.
• Esperar uma auditoria de segurança completa. Estas verificações tratam das portas de entrada. Elas não dizem nada sobre malware, alterações de arquivos ou plugins desatualizados.

Sem plugin

Os cinco comandos curl do passo 1 são o método manual, e vale a pena conhecê-los. Leia os resultados assim:

• HTTP/2 200 no wp-login.php: o login padrão é público. 404: ele está oculto.
• XML-RPC server accepts POST requests only. no xmlrpc.php: o endpoint está ativo. Para saber se o login é aceito, você teria de enviar uma chamada wp.getUsersBlogs com uma conta de teste.
• Um array JSON em /wp/v2/users com campos "slug": os nomes de usuário são públicos. 401 ou um array vazio: fechado.
• Location: /author/name/ em ?author=1: um vazamento. Repita com 2, 3 e assim por diante para ver quantos usuários um bot conseguiria coletar.
• 200 no sitemap de usuários: as URLs dos autores estão listadas.

A desvantagem é o tempo e a interpretação. Você precisa repetir tudo depois de cada mudança, e testar direito o login via XML-RPC significa montar o XML na mão.

Se algo der errado

• A varredura diz "aberto", mas você desativou. Limpe os caches de página e da CDN e verifique de novo. Se continuar aberto, outro plugin ou uma regra do servidor pode estar sobrepondo a configuração.
• A varredura não consegue alcançar o seu site. Algumas hospedagens impedem que um site faça requisições a si mesmo (loopback). Peça à sua hospedagem para liberar as requisições de loopback ou use o método curl de fora.
• Um nome de usuário ainda vaza depois da blindagem. Confira a caixa de autor do seu tema e o sitemap de autores de qualquer plugin de SEO. Mude o nome de exibição do autor se o tema o mostrar.

Com o Hushfort

A Varredura de Superfície fica no painel Blindagem de Superfície do Hushfort Security, o plugin de segurança gratuito para WordPress. Ela mede o que o seu site realmente expõe com requisições reais, assim como o método manual, e lista pelo nome os usuários que encontrar. Cada achado corresponde a uma camada do Hushfort que o fecha:

• Login via XML-RPC → Trava de Backdoor (Pro)
• Lista de usuários da REST, varreduras de autores, sitemap → Escudo de Nomes de Usuário (Pro)
• Login padrão → Ocultar Login (gratuito)

Criamos a Varredura de Superfície depois que uma loja continuou recebendo tentativas de senha pelo XML-RPC mesmo com a página de login oculta. A configuração parecia certa; só uma requisição real mostrou a porta aberta.