Em resumo: A forma mais eficaz de proteger a área de administração é abri-la apenas a redes conhecidas: através de uma lista de IP no servidor web, de uma VPN com endereço de saída fixo ou de uma segunda autenticação prévia. São importantes uma lista completa de todos os endereços de administração, o tratamento correto de proxies e CDN e um teste a partir do exterior. A proteção complementa a autenticação de dois fatores e as atualizações, não as substitui.
Porque é que o backend está aberto?
Em muitas empresas, os administradores atualizaram o PHP na semana passada e reiniciaram os workers. Quem depois consulta os registos de acesso verifica muitas vezes outra coisa: a página de início de sessão do CMS, a ferramenta de base de dados e o painel de alojamento são acedidos a toda a hora, de todo o mundo. Mas só são necessários a um punhado de pessoas da própria equipa.
Cada um destes endereços é superfície de ataque. Os formulários de início de sessão são testados por tentativa e erro, as ferramentas de administração têm falhas próprias e os plugins do backend são muitas vezes menos bem verificados do que o núcleo de um CMS. Se estranhos nem sequer conseguirem chegar a estas áreas, muitos ataques falham antes de começar.
Com honestidade: contra o próprio PHP2Shell isto ajuda pouco. As vulnerabilidades estão no interpretador e, segundo o php.net, podem ser desencadeadas sem autenticação através de páginas PHP públicas. A proteção do backend é um reforço duradouro, não um patch de emergência.
Proteger a área de administração com IP, VPN ou segunda autenticação
Não existe um único método correto. O decisivo é a forma como a sua equipa trabalha e onde o site está alojado.
| Método | Adequado para | Limite |
|---|---|---|
| Lista de IP no servidor web | escritório com endereço fixo, equipas pequenas | endereços variáveis em teletrabalho, manutenção da lista |
| VPN com endereço de saída fixo | equipas distribuídas, prestadores de serviços | a própria VPN tem de estar bem protegida e atualizada |
| Autenticação prévia (autenticação HTTP) | complemento quando não é possível um endereço fixo | palavra-passe adicional, só faz sentido com TLS |
| Certificados de cliente | poucos dispositivos geridos de forma fixa | a emissão e a revogação dos certificados exigem disciplina |
| Nome de anfitrião próprio apenas na rede interna | ambientes maiores com DNS interno | reestruturação da aplicação, nem todos os CMS o suportam |
Na prática, uma combinação dá bons resultados: autorização apenas para a VPN ou a rede da empresa, mais uma segunda autenticação como nível de recurso. O início de sessão propriamente dito no CMS mantém-se com autenticação de dois fatores, como descrito no guia Configurar a autenticação de dois fatores para acessos de administração.
Que endereços fazem realmente parte do backend?
O ponto fraco mais frequente não é a técnica, mas uma lista incompleta. Por isso, proceda nesta ordem:
- Registar as páginas de início de sessão do CMS ou da loja, incluindo endereços de login alternativos criados por plugins.
- Procurar ferramentas de administração: interfaces de base de dados, gestores de ficheiros, scripts de instalação, páginas de estado e de monitorização.
- Incluir painéis de alojamento e de servidor, que muitas vezes correm em portas próprias.
- Verificar instâncias de teste e de staging, que muitas vezes usam as mesmas credenciais que o site em produção.
- Delimitar interfaces: alguns caminhos do backend são também chamados pelo frontend público, por exemplo para pedidos Ajax. Não os deve bloquear às cegas, ou os formulários e carrinhos de compras deixam de funcionar.
O ponto cinco é a razão pela qual uma proteção tem sempre de ser testada. No WordPress, por exemplo, um ficheiro na pasta de administração é usado também para funções públicas.
Configuração: lista de IP mais segunda autenticação
No Nginx é possível combinar as duas condições. Com satisfy all, um pedido tem de vir de uma rede autorizada e, além disso, passar a segunda autenticação. O caminho, os endereços e a passagem para o PHP são marcadores de posição:
location ^~ /backend/ {
satisfy all;
allow 192.0.2.0/24; # rede da empresa (marcador de posição)
allow 198.51.100.10; # saída da VPN (marcador de posição)
deny all;
auth_basic "Interner Bereich";
auth_basic_user_file /etc/nginx/htpasswd-backend;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}
A location PHP aninhada é importante: com ^~, as outras regras para .php deixam de ser avaliadas. No Apache obtém-se o mesmo com um bloco em que ambas as condições têm de se verificar:
<Location "/backend">
AuthType Basic
AuthName "Interner Bereich"
AuthUserFile /etc/apache2/htpasswd-backend
<RequireAll>
Require ip 192.0.2.0/24 198.51.100.10
Require valid-user
</RequireAll>
</Location>
O ficheiro de palavras-passe deve ficar fora do webroot. A segunda autenticação transmite as credenciais em cada pedido, por isso só deve ser usada através de HTTPS.
Antes de qualquer alteração, mantenha aberta uma segunda via de acesso ao servidor, por exemplo uma sessão SSH existente. Quem se tranca de fora precisa, de outro modo, do fornecedor de alojamento.
As armadilhas: CDN, proxy, IPv6 e teletrabalho
Se o seu site estiver atrás de uma CDN como a Cloudflare ou de um balanceador de carga, o servidor web vê, à partida, apenas os endereços destes. Uma lista de IP bloquearia então todos ou deixaria passar todos. O servidor web tem de assumir o endereço real a partir de um cabeçalho: no Nginx com set_real_ip_from e real_ip_header, no Apache com mod_remoteip.
Aplica-se o seguinte: aceite o cabeçalho apenas dos endereços do seu próprio proxy. Caso contrário, qualquer visitante pode simular uma origem à sua escolha. É igualmente importante que o servidor de origem não esteja acessível diretamente, pois de outro modo o proxy e as suas regras podem ser contornados. Encontra indicações em Firewall para servidores web.
Há mais dois pontos frequentemente esquecidos. Se o servidor for acessível por IPv6, também os endereços IPv6 da sua rede precisam de uma entrada, ou os administradores com IPv6 ficam à frente de um bloqueio. E as ligações privadas à Internet mudam de endereço regularmente. Para teletrabalho e prestadores de serviços externos, uma VPN é por isso normalmente a solução mais estável.
Como verificar se a proteção funciona
Uma regra que não foi testada não conta como implementada. Verifique a partir de uma ligação fora da rede da empresa, por exemplo através da rede móvel:
# Esperado: 403 (bloqueado) ou 401 (segunda autenticação exigida)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Verificar também diretamente os ficheiros PHP, não só o diretório
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
Depois, as mesmas chamadas a partir da rede da empresa ou da VPN: aí a página tem de estar acessível. Controle em seguida o frontend público, ou seja, formulários, pesquisa e carrinho de compras. Nos registos dos dias seguintes, os acessos aos endereços de administração devem aparecer quase só com o estado 401 ou 403.
Se a área esteve aberta até agora, vale a pena olhar para as contas existentes. Como encontrar administradores desconhecidos é descrito em Encontrar contas de administrador estranhas no CMS e no servidor. Como complemento, uma proteção contra tentativas em massa trava os ataques, ver Proteger logins de administração contra brute force.
Como ajuda concretamente a PHP SOS?
- Registamos todos os endereços de administração dos seus sites, painéis e ferramentas e separamo-los dos caminhos necessários ao público.
- Escolhemos consigo o método adequado, em função da dimensão da equipa, do teletrabalho e do alojamento.
- Implementamos as regras no servidor web, tendo em conta CDN, proxy e IPv6, e mantendo sempre uma via de retorno aberta.
- Testamos a partir do exterior e do interior e entregamos uma breve documentação com as redes autorizadas.
A proteção das áreas de administração faz parte do nosso reforço de segurança de servidores para servidores web PHP.
Perguntas frequentes
Uma palavra-passe segura para o início de sessão do CMS não é suficiente?
Uma palavra-passe forte e a autenticação de dois fatores são obrigatórias, mas protegem apenas o próprio início de sessão. Falhas em páginas de login, plugins ou ferramentas de administração continuam acessíveis a qualquer pessoa. Uma proteção ao nível da rede ou do servidor web faz com que estranhos nem sequer cheguem lá.
O que faço se os meus colaboradores tiverem endereços IP variáveis?
Nesse caso, uma VPN com endereço de saída fixo é normalmente melhor solução do que uma lista de endereços individuais. Todos os administradores ligam-se primeiro à VPN e o servidor web autoriza apenas o endereço desta. Em alternativa, serve uma segunda autenticação prévia.
Um bloqueio por IP funciona também atrás da Cloudflare ou de um balanceador de carga?
Só se o servidor web assumir o endereço real do visitante a partir de um cabeçalho de confiança e aceitar esse cabeçalho exclusivamente do proxy próprio. Caso contrário, vê apenas os endereços do proxy ou confia em indicações falsificadas. Além disso, o servidor de origem não deve estar acessível diretamente a partir da Internet.
Uma área de administração protegida protege contra o PHP2Shell?
Só de forma muito limitada. As vulnerabilidades do PHP2Shell estão no interpretador PHP e podem ser exploradas sem autenticação através de qualquer página PHP pública. Contra o PHP2Shell ajuda a atualização do PHP seguida do reinício de todos os workers; a proteção apenas reduz a restante superfície de ataque.