Firewall y aislamiento de red del servidor

Servicios DevOps · España

Firewall y aislamiento de red del servidor en España, con el mismo principio de siempre: nada abierto al exterior que no lo necesite. Configuramos denegación por defecto, dejamos públicos solo los puertos 80 y 443, y todo lo demás (bases de datos, paneles, Redis, colas) queda cerrado o accesible solo por red privada o VPN, con auditoría periódica de puertos para detectar desviaciones.

  • Solo 80 y 443 abiertos al exterior
  • Ninguna base de datos con IP pública
  • Auditoría periódica de puertos, con alerta
Habla con un ingenieroVer abonamientos
  • VPS 1–8 h/mes; dedicados 5-10 h/mes según el plan; GPU 10 h/mes
    Horas incluidas
  • Frankfurt, en la UE
    Datacenters
  • protección DDoS L3/L4 incluida
    Red
  • en EUR, con IVA del 21 % desglosado en factura
    Facturación

Denegación por defecto, no lista de excepciones

El punto de partida es el contrario de lo que suele haber en un servidor sin revisar: en lugar de abrir puertos según hacen falta y olvidarse de cerrarlos después, empezamos denegando todo el tráfico entrante y solo abrimos explícitamente lo imprescindible, normalmente 80 y 443 para el tráfico web. Todo lo demás (acceso administrativo, bases de datos, colas de mensajes) se queda cerrado al exterior o solo accesible desde tu red privada o VPN.

  • Denegación por defecto en entrada, salida restringida a lo necesario
  • Solo 80 y 443 abiertos al público en la mayoría de los casos
  • Todo lo administrativo, solo por red privada o VPN

Buenas prácticas que aplicamos

Un firewall bien configurado el día del despliegue se degrada con el tiempo si nadie lo revisa: un puerto que alguien abrió temporalmente para depurar algo y nunca volvió a cerrar es el patrón más habitual que encontramos al auditar servidores de otros proveedores. Por eso la auditoría periódica es tan importante como la configuración inicial, y los resultados llegan a tu panel de cliente con la fecha exacta de cada apertura.

  • Denegación por defecto en entrada, salida restringida
  • Segmentación por niveles: borde, aplicación y datos en redes separadas
  • Ninguna base de datos, Redis o Mongo con IP pública
  • Auditoría de puertos externa periódica (nmap desde fuera) con alerta ante cambios
  • Registro de conexiones y reglas geográficas o por ASN cuando está justificado

Segmentación por niveles

No todos los servidores de tu infraestructura deberían poder hablar entre sí sin restricción. Separamos el tráfico en niveles (borde público, capa de aplicación, capa de datos) con reglas de firewall que solo permiten la comunicación estrictamente necesaria entre ellos: el nivel de aplicación puede hablar con el de datos, pero el nivel de borde nunca accede directamente a la base de datos. Añadimos Fail2ban o CrowdSec para bloquear automáticamente intentos de acceso repetidos y sospechosos.

  • Borde, aplicación y datos en segmentos de red separados
  • Fail2ban o CrowdSec para bloqueo automático de intentos sospechosos
  • Filtrado de tráfico de salida (egress) además del de entrada

Cómo usas las horas incluidas

Las horas DevOps forman parte del abonamiento: entre 1 y 8 horas al mes en VPS, entre 5 y 10 horas al mes en dedicados según el plan y 10 horas al mes en GPU. Se solicitan desde el panel de cliente, en Servicios DevOps. Se usan habitualmente para la auditoría inicial de un servidor existente, la migración hacia una configuración de denegación por defecto sin cortar servicios en producción, o la investigación de un puerto abierto que no debería estarlo. Lo que supera la cuota mensual se acepta y se factura por separado.

Cada suscripción incluye horas mensuales de DevOps, CyberSecurity y Programación: 1 h desde el plan cPanel Advanced, 1–8 h en VPS, entre 5 y 10 h en servidores dedicados según el plan y 10 h en servidores GPU. Las horas se solicitan desde el panel de cliente, no se acumulan al mes siguiente, y lo que supera la cuota se acepta y se factura por separado.

Cómo trabajamos

  1. Solicitas el trabajo desde el panel

    Describes tu infraestructura actual y si ya sospechas de puertos abiertos innecesarios o quieres una auditoría completa desde cero.

  2. Acordamos alcance y plazo

    Definimos la segmentación adecuada, qué queda público y qué pasa a red privada, y cuántas horas de tu cuota mensual cubre el trabajo.

  3. Aplicamos los cambios sin cortar servicios

    Migramos la configuración de forma progresiva, verificando en cada paso que los servicios legítimos siguen funcionando antes de cerrar el siguiente puerto.

  4. Entrega con auditoría documentada

    Recibes el informe de puertos abiertos antes y después, la configuración documentada y el calendario de auditorías periódicas acordado.

Casos de uso

Startup con servidor heredado sin revisar

Un equipo que hereda un servidor configurado por otra persona hace tiempo descubre en la auditoría inicial una base de datos accesible desde internet sin que nadie lo supiera, cerrada en la misma semana.

Empresa con obligación contractual de auditoría

Un proveedor que trabaja para un cliente del sector financiero necesita demostrar auditorías de puertos periódicas como parte del contrato: se las entregamos documentadas cada trimestre.

SaaS con varios servicios internos

Una plataforma con base de datos, caché y cola de mensajes en servidores distintos segmenta el acceso entre ellos por niveles, de forma que un fallo de configuración en el frontend no exponga directamente la base de datos.

Tecnologías

  • nftables
  • UFW
  • Fail2ban
  • CrowdSec
  • Wazuh
  • nmap

Preguntas frecuentes

  • ¿Qué puertos debo cerrar en mi servidor?

    En general, todos los que no necesites de forma pública. Si tu servidor solo sirve una web, únicamente 80 y 443 deberían estar abiertos al exterior; el resto (SSH, bases de datos, paneles de administración) debería quedar cerrado o accesible solo por VPN o red privada. Lo correcto es partir de denegación por defecto y abrir explícitamente lo imprescindible.

  • ¿Cuáles son los puertos de red inseguros?

    No hay una lista fija de puertos «inseguros» en sí mismos: el riesgo está en tener abierto al público cualquier servicio que no está pensado para exposición directa, como una base de datos (5432, 3306, 27017), Redis (6379) o un panel de administración. El problema no es el número de puerto, es la exposición innecesaria.

  • ¿Cómo abrir y cerrar puertos en un servidor?

    Con herramientas de firewall como nftables o UFW, que definen reglas de entrada y salida por puerto y protocolo. Configuramos denegación por defecto y abrimos explícitamente solo lo necesario, en lugar de abrir todo y cerrar después lo que parece sospechoso, que es el enfoque inverso y más arriesgado.

  • ¿Cómo reducir la superficie de ataque de un VPS?

    Cerrando todo puerto que no necesites públicamente, moviendo el acceso administrativo a VPN, segmentando la red por niveles y auditando periódicamente desde fuera con herramientas como nmap para detectar si algo se ha abierto sin que lo hayas decidido tú.

  • ¿Qué es la segmentación de red?

    Es dividir tu infraestructura en niveles (por ejemplo borde público, aplicación y datos) con reglas de firewall que solo permiten la comunicación estrictamente necesaria entre ellos. Así, si un atacante compromete el nivel de borde, no tiene automáticamente acceso directo a la base de datos.

  • ¿UFW o nftables?

    UFW es una capa simplificada sobre iptables/nftables, más fácil de configurar para reglas básicas. nftables ofrece más control y mejor rendimiento para configuraciones complejas o segmentación avanzada. Para servidores simples solemos usar UFW; para infraestructuras segmentadas con varias reglas, nftables directamente.

¿Sabes con certeza qué puertos tiene abiertos tu servidor?

Pedimos una auditoría externa de tu infraestructura actual y te decimos qué cerrar, con las horas incluidas en tu abonamiento.

Habla con un ingenieroVer abonamientos

Guías para empresas en España