18. Hardening de servidores y servicios expuestos: web, SSH, bases de datos, correo y DNS

18.1 Introducción

Un servidor puede estar bien configurado a nivel de sistema operativo, pero seguir siendo vulnerable si los servicios que ofrece están mal expuestos. Web, SSH, bases de datos, correo y DNS son ejemplos de servicios muy utilizados y muy atacados.

El hardening de servicios busca que cada servicio escuche solo donde debe, acepte solo usuarios o sistemas autorizados, use protocolos seguros, registre eventos importantes y se mantenga actualizado.

En este tema veremos controles comunes y recomendaciones específicas para los servicios más habituales.

18.2 Principios generales para servicios expuestos

Antes de entrar en cada servicio, conviene establecer principios comunes.

• Publicar solo servicios necesarios.
• Limitar origen mediante firewall, VPN, bastión o reglas de acceso.
• Usar cifrado cuando el servicio transporte información sensible.
• Aplicar autenticación fuerte.
• Eliminar usuarios, módulos y extensiones innecesarias.
• Actualizar software y dependencias.
• Registrar eventos relevantes.
• Separar servicios públicos de redes internas sensibles.
• Monitorear intentos fallidos, errores y patrones anómalos.

18.3 Inventario de servicios

No se puede endurecer lo que no se conoce. El primer paso es inventariar qué servicios existen, dónde están, quién los administra y por qué están expuestos.

18.4 Hardening de servicios web

Los servicios web suelen estar expuestos a usuarios externos, integraciones y bots. Pueden recibir tráfico legítimo y ataques por el mismo puerto, normalmente HTTP o HTTPS.

Controles recomendados:

• Usar HTTPS con TLS correctamente configurado.
• Redirigir HTTP a HTTPS cuando corresponda.
• Deshabilitar versiones antiguas de TLS y cifrados débiles.
• Eliminar módulos, extensiones y páginas de prueba.
• Ocultar o reducir banners de versión cuando sea posible.
• Aplicar WAF para aplicaciones expuestas.
• Limitar métodos HTTP innecesarios.
• Registrar accesos, errores y eventos de seguridad.

18.5 Cabeceras de seguridad web

Las cabeceras HTTP de seguridad ayudan a los navegadores a aplicar ciertas protecciones. No corrigen vulnerabilidades por sí solas, pero reducen riesgos comunes.

18.6 Hardening de SSH

SSH es un protocolo de administración remota muy usado. Es seguro cuando se configura bien, pero riesgoso si se expone sin control.

Buenas prácticas:

• No exponer SSH libremente a internet.
• Permitir acceso solo desde VPN, bastión o redes administrativas.
• Usar autenticación por clave o mecanismos fuertes.
• Deshabilitar acceso directo de cuentas privilegiadas cuando sea posible.
• Limitar usuarios o grupos autorizados.
• Registrar intentos exitosos y fallidos.
• Aplicar bloqueo o demora ante intentos repetidos.
• Mantener el servicio actualizado.

18.7 Hardening de bases de datos

Las bases de datos suelen contener información sensible. En general, no deberían estar expuestas directamente a internet ni a redes de usuarios.

Controles recomendados:

• Permitir acceso solo desde aplicaciones o redes autorizadas.
• Usar cuentas específicas por aplicación.
• Aplicar mínimo privilegio en permisos de base de datos.
• Deshabilitar cuentas por defecto o de ejemplo.
• Proteger credenciales y rotarlas cuando corresponda.
• Cifrar conexiones si hay tránsito por redes no confiables.
• Registrar accesos, errores y acciones administrativas.
• Aplicar parches de motor y extensiones.

18.8 Permisos en bases de datos

Una aplicación no siempre necesita permisos de administrador sobre la base de datos. Dar permisos excesivos aumenta el impacto de una vulnerabilidad en la aplicación.

18.9 Hardening de correo

El correo es un servicio crítico y una vía frecuente de abuso. Puede ser usado para phishing, spam, suplantación, distribución de malware o exfiltración.

Controles recomendados:

• Configurar autenticación de correo como SPF, DKIM y DMARC.
• Filtrar adjuntos peligrosos y enlaces sospechosos.
• Usar TLS para transporte cuando corresponda.
• Evitar relay abierto.
• Aplicar antispam y antimalware.
• Registrar envíos, rechazos, autenticaciones y errores.
• Proteger cuentas con MFA.
• Revisar reglas de reenvío sospechosas.

18.10 Hardening de DNS

DNS es esencial para la operación. Si se configura mal, puede facilitar abuso, exposición de información o interrupciones.

Buenas prácticas:

• Separar DNS público y DNS interno.
• Evitar resolutores abiertos a internet.
• Limitar transferencias de zona a servidores autorizados.
• Registrar consultas relevantes cuando sea necesario.
• Monitorear dominios sospechosos o túneles DNS.
• Aplicar parches al servicio DNS.
• Proteger administración del DNS.
• Usar controles como DNSSEC cuando el contexto lo justifique.

18.11 TLS y certificados

TLS protege comunicaciones en tránsito, pero debe configurarse correctamente. Un certificado válido no garantiza que toda la configuración sea segura.

Aspectos a revisar:

• Certificados vigentes y emitidos para el nombre correcto.
• Renovación antes del vencimiento.
• Deshabilitar versiones antiguas de TLS.
• Evitar algoritmos débiles.
• Proteger claves privadas.
• Monitorear vencimientos.
• Usar cadenas de confianza completas.

18.12 Cuentas y secretos de servicios

Muchos servicios usan credenciales para conectarse a bases de datos, APIs, correo u otros sistemas. Esos secretos deben protegerse.

Buenas prácticas:

• No guardar contraseñas en texto plano en archivos expuestos.
• Usar gestores de secretos cuando sea posible.
• Asignar permisos mínimos a cuentas de servicio.
• Rotar secretos según política o ante sospecha.
• Evitar reutilizar la misma credencial en varios servicios.
• Registrar uso de credenciales privilegiadas.

18.13 Logs de servicios expuestos

Los servicios expuestos deben generar logs útiles. Sin registros, es difícil saber si hubo explotación, abuso o error de configuración.

Eventos a registrar:

• Accesos exitosos y fallidos.
• Errores de autenticación.
• Cambios administrativos.
• Peticiones web sospechosas.
• Consultas DNS inusuales.
• Rechazos de correo y eventos antispam.
• Errores de base de datos.
• Uso de cuentas privilegiadas.

18.14 Monitoreo y alertas

Además de registrar, hay que monitorear señales importantes.

Alertas útiles:

• Muchos intentos fallidos de SSH.
• Errores 500 o picos anómalos en aplicación web.
• Consultas DNS a dominios sospechosos.
• Intentos de relay en correo.
• Conexiones a base de datos desde orígenes no autorizados.
• Vencimiento próximo de certificados.
• Cambios inesperados en configuración de servicio.

18.15 Segmentación de servicios

La segmentación limita qué sistemas pueden comunicarse con cada servicio. Es una de las formas más efectivas de reducir impacto.

Ejemplos:

• Internet solo llega al reverse proxy o WAF.
• El reverse proxy solo llega a servidores web internos.
• La aplicación solo llega a la base de datos por el puerto requerido.
• Los usuarios no acceden directamente a bases de datos.
• La administración solo se permite desde bastión.
• DNS interno no se expone a internet.

18.16 Ejemplo práctico: servicio web público

Una publicación web defensiva podría incluir:

1. Servicio ubicado en DMZ o detrás de reverse proxy.
2. Acceso externo solo por HTTPS.
3. TLS actualizado y certificado válido.
4. WAF con reglas ajustadas.
5. Servidor actualizado y sin módulos innecesarios.
6. Aplicación con permisos mínimos hacia backend.
7. Logs enviados a plataforma central.
8. Alertas por errores, explotación y patrones anómalos.

18.17 Ejemplo práctico: base de datos interna

Una base de datos interna debería protegerse con controles como:

• No exposición directa a internet.
• Acceso solo desde servidores de aplicación autorizados.
• Cuentas separadas por aplicación.
• Permisos mínimos sobre tablas y operaciones.
• Registro de accesos administrativos.
• Cifrado de conexión cuando corresponda.
• Backups protegidos y probados.
• Monitoreo de consultas o acciones inusuales.

18.18 Errores frecuentes

• Publicar administración remota: SSH, RDP o paneles no deberían estar abiertos sin restricciones.
• Exponer bases de datos: normalmente deben quedar en redes internas controladas.
• No configurar TLS correctamente: cifrado débil reduce protección real.
• Dejar módulos de prueba: agregan superficie innecesaria.
• No revisar logs: registrar sin monitorear aporta poco.
• Usar credenciales compartidas: dificulta trazabilidad y aumenta impacto.
• No separar DNS interno y público: puede revelar información sensible.

18.19 Lista de verificación inicial

• Inventariar servicios expuestos, puertos, responsables y criticidad.
• Eliminar servicios, módulos y cuentas innecesarias.
• Aplicar parches de servicios y dependencias.
• Limitar acceso por firewall, VPN, bastión o segmentación.
• Usar TLS seguro cuando corresponda.
• Proteger cuentas y secretos de servicio.
• Configurar logs útiles y enviarlos a una plataforma central.
• Activar alertas para señales relevantes.
• Separar servicios públicos de redes internas sensibles.
• Revisar configuraciones después de cambios o actualizaciones.

18.20 Ideas clave para recordar

• Un servicio expuesto aumenta superficie de ataque y debe justificarse.
• Web, SSH, bases de datos, correo y DNS requieren controles específicos.
• La publicación segura combina segmentación, firewall, hardening y monitoreo.
• TLS protege el tránsito, pero necesita configuración correcta.
• Las cuentas de servicio deben tener permisos mínimos y secretos protegidos.
• Logs y alertas son parte del hardening operativo.

18.21 Conclusión

Endurecer servicios expuestos reduce el riesgo en puntos que naturalmente reciben tráfico. La clave es publicar solo lo necesario, limitar quién puede acceder, proteger credenciales, actualizar componentes y monitorear actividad.

En el próximo tema estudiaremos hardening de red: routers, switches, Wi-Fi, administración remota y protocolos seguros.