La mayoría de brechas de seguridad no explotan vulnerabilidades sofisticadas. Explotan configuraciones por defecto, servicios expuestos sin necesidad y sistemas que llevan meses sin actualizarse. Un servidor mal configurado es una puerta abierta: puede que nadie la fuerce hoy, pero los bots no descansan.
Me ocupo de cerrar esa puerta antes de que haya un problema. Auditoría del estado actual, reducción de la superficie de ataque y configuración de las capas de defensa que corresponden a cada servicio. Sin instalar suites pesadas ni soluciones de caja negra: infraestructura tuya, configurada bien, con todo documentado.
Trabajo con agencias y desarrolladores que necesitan dejar los servidores de sus clientes en buen estado antes de entregar un proyecto, y con responsables de e-commerce y empresas que quieren saber qué nivel de exposición tienen.
Síntomas habituales
- Servidor recién montado sin revisar. Viene con el usuario root con acceso SSH por contraseña, puertos abiertos que no se usan y servicios por defecto. Un hosting o una VPS por defecto no es un servidor seguro.
- Ataques de fuerza bruta continuos. SSH, wp-login, xmlrpc, paneles de administración… los logs están llenos de intentos y nadie ha configurado nada para cortarlos.
- Nadie sabe qué puertos o servicios están expuestos. El firewall «está activado» pero nadie ha revisado las reglas ni qué escucha en qué puerto desde hace tiempo.
- Actualizaciones de seguridad pendientes. El sistema operativo, el kernel o los servicios del stack llevan meses sin actualizarse. Cada semana que pasa, hay más CVEs conocidos explotables.
- Auditoría necesaria antes de una entrega o certificación. Un cliente pide evidencias de seguridad, hay una auditoría externa prevista, o simplemente quieres saber el estado real antes de entregar.
Cómo lo abordo
El punto de partida es siempre el mismo: saber el estado real antes de tocar nada. Nada de aplicar una checklist genérica sin entender el entorno. Primero audito, luego priorizo por impacto real, y después aplico los cambios con documentación de cada decisión.
El objetivo no es un servidor «perfecto» en el papel, sino un servidor con una superficie de ataque razonable, con las capas de defensa activas donde importan y con el registro suficiente para detectar anomalías.
Qué cubre este servicio
Auditoría de seguridad del sistema
- Revisión de puertos expuestos, servicios activos y usuarios del sistema.
- Análisis de configuraciones por defecto, permisos de ficheros y directorios sensibles.
- Revisión de logs en busca de indicios de accesos sospechosos o intentos previos.
- Informe con hallazgos clasificados por severidad y recomendaciones concretas.
Hardening del sistema
- Configuración de SSH: autenticación por clave, deshabilitar root, cambio de puerto si aplica, límites de acceso.
- Configuración del cortafuegos (iptables, nftables, pf en BSD): política restrictiva, solo lo necesario abierto.
- Reducción de la superficie de ataque: eliminar servicios innecesarios, revisar crons y usuarios.
- Configuración de fail2ban u equivalente para bloqueo automático de fuerza bruta (SSH, HTTP, servicios específicos).
- Cabeceras de seguridad HTTP, TLS bien configurado y renovación automática de certificados.
- Actualizaciones de seguridad del sistema operativo, kernel y paquetes del stack.
Protección a nivel de aplicación web
- Protección de endpoints sensibles: wp-login, xmlrpc, paneles de administración, APIs.
- Filtrado de bots y scrapers a nivel de servidor web antes de que lleguen a tu app.
- WAF a nivel de servidor (ModSecurity) o perimetral (Cloudflare) según el caso.
- Permisos correctos de ficheros y directorios en el docroot.
Seguridad continua
- Gestión de actualizaciones de seguridad del sistema de forma periódica.
- Revisión de logs y alertas ante anomalías.
- Re-auditoría tras cambios relevantes en la infraestructura.