Seguridad GeoServer: mantener actualizado un servidor expuesto

Por qué un GeoServer expuesto debe estar actualizado

GeoServer responde por naturaleza a peticiones del exterior: su función es servir mapas y entidades a clientes que no conoce. Cada petición WMS, WFS o WPS la analiza el servidor, y un error en ese análisis puede convertirse en una puerta de entrada.

Como todo programa de este tamaño, GeoServer corrige fallos con regularidad. El proyecto publica versiones de mantenimiento y solo corrige las ramas que siguen mantenidas. Un servidor instalado hace dos años y nunca actualizado acumula, por tanto, fallos conocidos y documentados, a veces explotados por robots que recorren Internet.

La actualización no afecta solo a GeoServer. El servidor depende de un entorno Java, a menudo de un contenedor de servlets, de extensiones que deben seguir exactamente la misma versión y del sistema operativo de la máquina. Un fallo en cualquiera de esas capas expone todo lo demás. Mantener GeoServer actualizado es, por tanto, mantener actualizada toda la pila que lo sostiene.

El caso CVE-2024-36401: ejecución remota de código

El 1 de julio de 2024, el proyecto GeoServer publicó el aviso de seguridad GHSA-6jj6-gm7p-fcvv. La biblioteca GeoTools evaluaba los nombres de propiedades como expresiones XPath, lo que permitía ejecutar código arbitrario en el servidor sin autenticación mediante simples peticiones WFS, WMS o WPS. Todas las instalaciones por defecto estaban afectadas.

Fuentes consultadas el 09/11/2026: aviso GHSA-6jj6-gm7p-fcvv en el repositorio GitHub de GeoServer, y alerta de la CISA del 15 de julio de 2024 en cisa.gov que anuncia la inclusión en el catálogo KEV.

Este aviso muestra cómo leer cualquier boletín de seguridad de GeoServer. Localice primero las versiones afectadas y compárelas con la suya. Lea después las versiones corregidas: si su rama no tiene ninguna, la única salida es cambiar de rama. La puntuación de gravedad fija la urgencia: por encima de 9, se actúa el mismo día. El apartado de solución provisional indica qué hacer mientras llega la actualización, y a qué coste funcional. Por último, la inclusión en un catálogo de vulnerabilidades explotadas significa que ya hay ataques en curso: la pregunta ya no es si un servidor expuesto será atacado, sino cuándo. Guarde una breve nota de cada aviso evaluado, con la decisión tomada y su fecha.

Lo que enseña este fallo

• Un servicio público es una superficie de ataque. El fallo no exigía contraseña: proteger la consola de administración no bastaba.
• El plazo cuenta. Entre la publicación del aviso y las primeras explotaciones observadas pasó alrededor de una semana. Una actualización trimestral no protege de un fallo así.
• Las ramas antiguas siguen siendo vulnerables. Solo las ramas mantenidas recibieron corrección; una instalación demasiado antigua obligaba a cambiar de versión, no solo a aplicar un parche.
• Hay que saber qué está en marcha. Muchas organizaciones descubrieron un GeoServer olvidado, instalado para un proyecto anterior.

Seguridad GeoServer: buenas prácticas

• Cambiar la contraseña de administrador por defecto desde la instalación, y crear cuentas nominativas en lugar de compartir la cuenta admin.
• No exponer la consola de administración a todo Internet: reservarla a una red interna, una VPN o una lista de direcciones autorizadas.
• Mantenerse en una versión mantenida y seguir los avisos de seguridad del proyecto en geoserver.org y su repositorio GitHub.
• Activar solo los servicios útiles. Si WPS o WCS no se usan, desactívelos: menos servicios, menos superficie.
• Ajustar los permisos por espacio de trabajo y por capa, en particular la escritura WFS-T.
• Situar GeoServer detrás de un proxy inverso en HTTPS, y registrar las peticiones para detectar comportamientos anómalos.
• Usar cuentas de base de datos de solo lectura para los almacenes PostGIS que no necesitan escribir.

El primer punto no es teórico: la documentación de GeoServer indica que la consola se abre por defecto con el usuario admin y la contraseña geoserver. Esas credenciales las conoce todo el mundo, incluidos los robots que prueban los servidores expuestos. Un GeoServer en línea que todavía las acepte debe considerarse abierto.

Cuentas, roles y reglas de acceso

GeoServer gestiona sus propios usuarios, grupos y roles, y aplica dos familias de reglas. Las reglas de capas deciden quién puede leer, escribir o administrar cada espacio de trabajo y cada capa. Las reglas de servicios deciden quién puede llamar a una operación concreta, por ejemplo la escritura WFS. Según la documentación del proyecto, la configuración por defecto permite a cualquier usuario anónimo leer todas las capas y reserva la escritura a los administradores: razonable para datos públicos, mucho menos para un espacio que mezcla datos abiertos e internos.

# Capas: espacio.capa.modo=roles (r lectura, w escritura, a administración)
*.*.r=*
*.*.w=ROLE_ADMINISTRATOR
cadastre.*.r=ROLE_TECNICOS

# Servicios: servicio.operación=roles
wfs.Transaction=ROLE_EDITORES

• Un rol por uso, no por persona: lectores internos, editores, administradores. Después se añaden o retiran usuarios sin tocar las reglas.
• Separar los datos por espacio de trabajo: un espacio público y otro interno. Las reglas se escriben entonces con una línea por espacio en lugar de una por capa.
• Reservar la escritura WFS-T a un rol concreto, aunque el almacén PostGIS ya solo permita escribir en algunas tablas: dos cerrojos valen más que uno.
• No mezclar las dos familias para una misma necesidad: la documentación precisa que una regla de servicio no puede apuntar a una capa concreta. Para proteger una capa hace falta una regla de capa.
• Probar con una cuenta que no sea de administrador. Un administrador lo ve todo; solo una cuenta normal, o una sesión anónima, muestra lo que obtiene realmente el público.

No olvide la API REST, que permite configurarlo todo por programa: la documentación recomienda bloquearla con una regla general que reserve todos sus métodos al rol de administrador. Un script de automatización debe usar entonces una cuenta dedicada, con una contraseña distinta de las de las personas.

Configurar GeoServer para producción

Una instalación recién salida del paquete está pensada para descubrir el programa, no para estar expuesta. La documentación de GeoServer dedica una parte entera al paso a producción; estos son los ajustes que afectan directamente a la seguridad.

• Registro: elegir el perfil de producción, más sobrio, y conservar los registros el tiempo suficiente para reconstruir un incidente.
• Excepciones detalladas: la opción que añade la traza de llamadas Java a los mensajes de error sirve para depurar; la documentación la reserva a las pruebas. En producción informa innecesariamente a un atacante sobre el interior del servidor.
• Servicios globales: desactivados, obligan a los clientes a pasar por los servicios propios de cada espacio de trabajo, lo que aísla mejor los datos.
• Servicios inútiles: un servicio puede desactivarse desde la consola, o mediante una propiedad del sistema que enumera varios a la vez. Un WPS o un WCS que nadie llama no debe responder.
• Consola de administración: cuando la administración pasa por la API REST o por archivos desplegados, la consola web puede desactivarse por completo con una propiedad Java al arrancar. Si no, sigue accesible pero filtrada por el proxy inverso.

Anote cada ajuste en un documento de explotación, con su motivo. En la próxima actualización o el próximo cambio de administrador, ese documento evita volver por descuido a una configuración de demostración.

Una rutina de actualización realista

1. Suscribirse a los anuncios de seguridad de GeoServer y anotar la rama mantenida más reciente.
2. Hacer copia del directorio de datos (configuración, estilos, capas) antes de cualquier actualización.
3. Probar la nueva versión en una copia: capas, estilos SLD, extensiones instaladas.
4. Aplicar en producción y comprobar los GetCapabilities y algunas capas clave en QGIS.
5. Ante un fallo crítico, no esperar a la ventana habitual: aplicar el mismo día la corrección o la solución provisional publicada.

Esta rutina lleva tiempo, sobre todo cuando las extensiones deben seguir la misma versión. Es uno de los costes ocultos del alojamiento propio que detalla nuestra guía sobre el coste de un SIG web de código abierto.

Para que la fase de pruebas quepa en un día, prepare una lista de control fija: leer el GetCapabilities de cada servicio, mostrar tres o cuatro capas representativas en WMS, lanzar una petición WFS sobre una tabla grande, hacer una edición WFS-T si la ofrece, conectarse con una cuenta que no sea de administrador y leer los registros en busca de errores al arrancar. Compruebe también que todas las extensiones se han cargado. Si todo pasa en la copia, el paso a producción deja de ser un salto al vacío.

Inventariar, supervisar y reaccionar

La seguridad GeoServer empieza con una pregunta sencilla: ¿cuántos GeoServer funcionan en su organización y en qué versiones? Muchos equipos descubren, durante una alerta, un servidor de pruebas que quedó en línea o una instalación montada por un proveedor y luego olvidada. Una lista actualizada vale más que la mejor configuración aplicada a la mitad de los servidores.

• Inventariar cada GeoServer: dirección, versión, rama, extensiones instaladas, responsable, fecha de la última actualización.
• Comprobar la exposición desde fuera: desde una red ajena, la consola de administración no debe responder, mientras que los servicios públicos sí.
• Vigilar los registros: ráfagas de peticiones, parámetros inusuales en los filtros o llamadas WPS que nadie usa son señales de alerta.
• Preparar un plan de respuesta: quién decide detener un servicio, cómo cortarlo rápidamente, dónde está la última copia del directorio de datos.
• Aplicar las soluciones provisionales publicadas cuando la actualización no puede esperar. Para CVE-2024-36401, el aviso del proyecto proponía retirar un componente de GeoTools (gt-complex) hasta la actualización, a costa de algunas funciones avanzadas, o sustituir archivos corregidos en las versiones más antiguas.

Una solución provisional es temporal: reduce el riesgo mientras se planifica la verdadera actualización, no la sustituye. Por último, si sospecha una intrusión, actualizar no basta: hay que comprobar que no se haya dejado nada en el servidor entretanto y, si es necesario, partir de una instalación limpia con el directorio de datos restaurado.

Los errores de seguridad más frecuentes

La mayoría de estos errores no vienen de falta de competencia, sino de falta de tiempo: un servidor instalado para un proyecto y abandonado una vez entregado. Por eso la seguridad GeoServer depende sobre todo de la organización: un responsable designado, una lista actualizada y una rutina que se cumple, más que de un ajuste aislado.

Delegar la seguridad sin renunciar a GeoServer

Con GeoServer Cloud, LizPack instala, protege, actualiza y supervisa GeoServer. Usted trabaja en un espacio aislado, con la consola GeoServer habitual, sin gestionar Java ni servidor. Las capas de otras cuentas no son visibles ni accesibles.

Si sus datos deben quedarse en sus instalaciones, LizPack Entreprise instala GeoServer en su infraestructura, gestionado desde un portal. Para comparar las opciones de alojamiento, vea el alojamiento GeoServer en línea, y para situar GeoServer frente a otros servidores, nuestra comparativa.

Preguntas frecuentes