Segurança GeoServer: manter atualizado um servidor exposto

Porque é que um GeoServer exposto deve estar atualizado

O GeoServer responde por natureza a pedidos vindos do exterior: a sua função é servir mapas e entidades a clientes que não conhece. Cada pedido WMS, WFS ou WPS é analisado pelo servidor, e um erro nessa análise pode tornar-se uma porta de entrada.

Como qualquer software desta dimensão, o GeoServer corrige falhas com regularidade. O projeto publica versões de manutenção e só corrige os ramos ainda mantidos. Um servidor instalado há dois anos e nunca atualizado acumula, portanto, falhas conhecidas e documentadas, por vezes exploradas por robôs que percorrem a Internet.

A atualização não diz respeito apenas ao GeoServer. O servidor depende de um ambiente Java, muitas vezes de um contentor de servlets, de extensões que têm de acompanhar exatamente a mesma versão e do sistema operativo da máquina. Uma falha em qualquer destas camadas expõe todo o resto. Manter o GeoServer atualizado é, portanto, manter atualizada toda a pilha que o suporta.

O caso CVE-2024-36401: execução remota de código

A 1 de julho de 2024, o projeto GeoServer publicou o aviso de segurança GHSA-6jj6-gm7p-fcvv. A biblioteca GeoTools avaliava os nomes de propriedades como expressões XPath, o que permitia executar código arbitrário no servidor sem autenticação através de simples pedidos WFS, WMS ou WPS. Todas as instalações predefinidas estavam afetadas.

Fontes consultadas a 09/11/2026: aviso GHSA-6jj6-gm7p-fcvv no repositório GitHub do GeoServer, e alerta da CISA de 15 de julho de 2024 em cisa.gov que anuncia a inclusão no catálogo KEV.

Este aviso mostra como ler qualquer boletim de segurança do GeoServer. Identifique primeiro as versões afetadas e compare-as com a sua. Leia depois as versões corrigidas: se o seu ramo não tiver nenhuma, a única saída é mudar de ramo. A pontuação de gravidade fixa a urgência: acima de 9, age-se no próprio dia. A secção de solução provisória diz o que fazer enquanto a atualização não chega, e a que custo funcional. Por fim, a inclusão num catálogo de vulnerabilidades exploradas significa que já há ataques em curso: a questão deixa de ser se um servidor exposto será visado, mas quando. Guarde uma breve nota de cada aviso avaliado, com a decisão tomada e a data.

O que esta falha ensina

• Um serviço público é uma superfície de ataque. A falha não exigia palavra-passe: proteger a consola de administração não bastava.
• O prazo conta. Entre a publicação do aviso e as primeiras explorações observadas passou cerca de uma semana. Uma atualização trimestral não protege de uma falha deste tipo.
• Os ramos antigos continuam vulneráveis. Só os ramos mantidos receberam correção; uma instalação demasiado antiga obrigava a mudar de versão, não apenas a aplicar um patch.
• É preciso saber o que está a funcionar. Muitas organizações descobriram um GeoServer esquecido, instalado para um projeto antigo.

Segurança GeoServer: boas práticas

• Alterar a palavra-passe de administrador predefinida logo na instalação, e criar contas nominativas em vez de partilhar a conta admin.
• Não expor a consola de administração a toda a Internet: reservá-la a uma rede interna, uma VPN ou uma lista de endereços autorizados.
• Manter uma versão suportada e seguir os avisos de segurança do projeto em geoserver.org e no seu repositório GitHub.
• Ativar só os serviços úteis. Se o WPS ou o WCS não forem usados, desative-os: menos serviços, menos superfície.
• Definir permissões por espaço de trabalho e por camada, em particular a escrita WFS-T.
• Colocar o GeoServer atrás de um proxy inverso em HTTPS, e registar os pedidos para detetar comportamentos anómalos.
• Usar contas de base de dados só de leitura para os armazéns PostGIS que não precisam de escrever.

O primeiro ponto não é teórico: a documentação do GeoServer indica que a consola abre por predefinição com o utilizador admin e a palavra-passe geoserver. Estas credenciais são conhecidas de todos, incluindo os robôs que testam os servidores expostos. Um GeoServer online que ainda as aceite deve ser considerado aberto.

Contas, funções e regras de acesso

O GeoServer gere os seus próprios utilizadores, grupos e funções (roles), e aplica duas famílias de regras. As regras de camadas decidem quem pode ler, escrever ou administrar cada espaço de trabalho e cada camada. As regras de serviços decidem quem pode chamar uma determinada operação, por exemplo a escrita WFS. Segundo a documentação do projeto, a configuração predefinida deixa qualquer utilizador anónimo ler todas as camadas e reserva a escrita aos administradores: razoável para dados públicos, muito menos para um espaço que mistura dados abertos e internos.

# Camadas: espaco.camada.modo=funções (r leitura, w escrita, a administração)
*.*.r=*
*.*.w=ROLE_ADMINISTRATOR
cadastre.*.r=ROLE_TECNICOS

# Serviços: servico.operação=funções
wfs.Transaction=ROLE_EDITORES

• Uma função por uso, não por pessoa: leitores internos, editores, administradores. Depois acrescentam-se ou retiram-se utilizadores sem mexer nas regras.
• Separar os dados por espaço de trabalho: um espaço público e outro interno. As regras escrevem-se então com uma linha por espaço em vez de uma por camada.
• Reservar a escrita WFS-T a uma função precisa, mesmo que o armazém PostGIS já só permita escrever em algumas tabelas: dois trincos valem mais do que um.
• Não misturar as duas famílias para a mesma necessidade: a documentação precisa que uma regra de serviço não pode visar uma camada específica. Para proteger uma camada, é precisa uma regra de camada.
• Testar com uma conta que não seja de administrador. Um administrador vê tudo; só uma conta normal, ou uma sessão anónima, mostra o que o público obtém realmente.

Não esqueça a API REST, que permite configurar tudo por programa: a documentação recomenda bloqueá-la com uma regra geral que reserve todos os seus métodos à função de administrador. Um script de automatização deve então usar uma conta dedicada, com uma palavra-passe distinta das das pessoas.

Configurar o GeoServer para produção

Uma instalação acabada de sair do pacote está pensada para descobrir o software, não para ficar exposta. A documentação do GeoServer dedica uma parte inteira à passagem a produção; eis as configurações que afetam diretamente a segurança.

• Registos: escolher o perfil de produção, mais sóbrio, e guardar os registos tempo suficiente para reconstituir um incidente.
• Exceções detalhadas: a opção que acrescenta a pilha de chamadas Java às mensagens de erro serve para depuração; a documentação reserva-a aos testes. Em produção, informa desnecessariamente um atacante sobre o interior do servidor.
• Serviços globais: desativados, obrigam os clientes a passar pelos serviços próprios de cada espaço de trabalho, o que isola melhor os dados.
• Serviços inúteis: um serviço pode ser desligado a partir da consola, ou por uma propriedade de sistema que enumera vários de uma vez. Um WPS ou um WCS que ninguém chama não deve responder.
• Consola de administração: quando a administração passa pela API REST ou por ficheiros implementados, a consola web pode ser totalmente desativada por uma propriedade Java no arranque. Caso contrário, continua acessível mas filtrada pelo proxy inverso.

Registe cada configuração num documento de exploração, com o respetivo motivo. Na próxima atualização ou na próxima mudança de administrador, é esse documento que evita regressar, por descuido, a uma configuração de demonstração.

Uma rotina de atualização realista

1. Subscrever os anúncios de segurança do GeoServer e anotar o ramo mantido mais recente.
2. Fazer cópia do diretório de dados (configuração, estilos, camadas) antes de qualquer atualização.
3. Testar a nova versão numa cópia: camadas, estilos SLD, extensões instaladas.
4. Aplicar em produção e verificar os GetCapabilities e algumas camadas-chave no QGIS.
5. Perante uma falha crítica, não esperar pela janela habitual: aplicar no próprio dia a correção ou a solução provisória publicada.

Esta rotina leva tempo, sobretudo quando as extensões têm de acompanhar a mesma versão. É um dos custos escondidos do alojamento próprio descritos no nosso guia sobre o custo de um SIG web open source.

Para que a fase de testes caiba num dia, prepare uma lista de verificação fixa: ler o GetCapabilities de cada serviço, apresentar três ou quatro camadas representativas em WMS, lançar um pedido WFS sobre uma tabela grande, fazer uma edição WFS-T se a oferecer, entrar com uma conta que não seja de administrador e ler os registos à procura de erros no arranque. Verifique também que todas as extensões foram carregadas. Se tudo passar na cópia, a passagem a produção deixa de ser um salto no escuro.

Inventariar, monitorizar e reagir

A segurança GeoServer começa com uma pergunta simples: quantos GeoServer funcionam na sua organização, e em que versões? Muitas equipas descobrem, durante um alerta, um servidor de testes que ficou online ou uma instalação montada por um prestador e depois esquecida. Uma lista atualizada vale mais do que a melhor configuração aplicada a metade dos servidores.

• Inventariar cada GeoServer: endereço, versão, ramo, extensões instaladas, responsável, data da última atualização.
• Verificar a exposição a partir do exterior: a partir de uma rede alheia, a consola de administração não deve responder, ao passo que os serviços públicos respondem.
• Vigiar os registos: rajadas de pedidos, parâmetros invulgares nos filtros ou chamadas WPS que ninguém usa são sinais de alerta.
• Preparar um plano de resposta: quem decide parar um serviço, como cortá-lo rapidamente, onde está a última cópia do diretório de dados.
• Aplicar as soluções provisórias publicadas quando a atualização não pode esperar. Para a CVE-2024-36401, o aviso do projeto propunha retirar um componente do GeoTools (gt-complex) até à atualização, à custa de algumas funções avançadas, ou substituir ficheiros corrigidos nas versões mais antigas.

Uma solução provisória é temporária: reduz o risco enquanto se planeia a verdadeira atualização, não a substitui. Por fim, se suspeitar de uma intrusão, atualizar não basta: é preciso verificar que nada foi deixado no servidor entretanto e, se necessário, partir de uma instalação limpa com o diretório de dados restaurado.

Os erros de segurança mais frequentes

A maioria destes erros não vem de falta de competência, mas de falta de tempo: um servidor instalado para um projeto e depois posto de lado quando o projeto foi entregue. É por isso que a segurança GeoServer depende sobretudo da organização: um responsável designado, uma lista atualizada e uma rotina cumprida, mais do que uma configuração isolada.

Delegar a segurança sem abdicar do GeoServer

Com o GeoServer Cloud, o GeoServer é instalado, protegido, atualizado e monitorizado pela LizPack. Trabalha num espaço isolado, com a consola GeoServer habitual, sem gerir Java nem servidor. As camadas de outras contas não são visíveis nem acessíveis.

Se os seus dados têm de ficar nas suas instalações, a LizPack Entreprise instala o GeoServer na sua infraestrutura, gerido a partir de um portal. Para comparar as opções de alojamento, veja o alojamento GeoServer online e, para situar o GeoServer face a outros servidores, a nossa comparação.

Perguntas frequentes