Qué hacemos · Operaciones: El hardening baseline de cada host
Cada máquina que construimos parte de la misma base de seguridad, y la base no está en negociación. SELinux enforcing, un firewall de host más un par de firewalls de perímetro, política por red y por país en el perímetro, solo claves SSH, sin swap en las máquinas virtuales. Es lo que convierte lo «seguro» en una propiedad de la plataforma y no en una promesa en un contrato.
Qué es
Un conjunto fijo de controles aplicado a cada host Linux y a cada servicio público que operamos, desde el momento en que se instala la máquina. Está integrado en nuestras plantillas de instalación, de modo que un servidor nuevo está bastionado antes de que nadie inicie sesión en él, y se comprueba desde fuera después de cada cambio en lugar de confiarse desde dentro.
Cómo lo construimos
SELinux enforcing, siempre. Cuando una aplicación y la política no se ponen de acuerdo, escribimos o corregimos la política; no desactivamos la protección y no la tapamos con una regla generada que debilita en silencio todo el host. Cuando cambiamos el modo de aplicación en una máquina remota, antes se arma una red de seguridad temporizada, de modo que un error nunca pueda dejarnos fuera de la máquina.
Dos firewalls, no uno. Cada servicio público está detrás de un par de firewalls de alta disponibilidad en el perímetro, construido sobre Cisco Firepower u OPNsense, además del firewall de host. Los cambios de perímetro pasan únicamente por la API del firewall, primero el nodo en standby, y después se verifica que ambos nodos son idénticos.
Política por red y por país en el perímetro. Los servicios públicos llevan una lista de bloqueo de países mantenida y una lista de bloqueo de redes conocidas por abusos. Las plataformas privadas reciben lo contrario: una allowlist, donde solo países o redes designados pueden conectarse. Después de cada cambio, la política se prueba desde varios países para demostrar que hace lo que dice.
Acceso administrativo en una red separada. Los administradores llegan a un host a través de nuestras propias pasarelas VPN y jump hosts, en una red de gestión que el tráfico de los clientes no puede ver.
Sin swap en las máquinas virtuales. El disco de una máquina virtual vive en una cabina enterprise all-flash. El swap gastaría la resistencia de esa cabina como memoria de desbordamiento y convertiría una falta de memoria en un servidor lento e impredecible. Una máquina que necesita más memoria recibe más memoria, y la aplicación se ajusta para caber en ella.
El sistema de archivos correcto y los ajustes correctos. XFS en todas partes, y ajustes de storage adecuados a los discos reales que hay detrás de la controladora, de modo que el almacenamiento de estado sólido se trate como almacenamiento de estado sólido.
Parcheo desde nuestro propio mirror. Nuestro mirror de paquetes vive dentro de nuestro propio datacenter, con las firmas upstream intactas, accesible solo desde nuestros propios rangos de direcciones. Un servidor deliberadamente incapaz de llegar a internet sigue siendo un servidor que podemos parchear por completo.
Sin estado donde no hace falta estado. Los servicios UDP que no necesitan seguimiento de conexiones, como el DNS, se pasan sin estado en el firewall, y el procesamiento de paquetes se reparte entre los núcleos del procesador con el plano de control separado, de modo que el firewall se mantiene rápido bajo carga.
De qué le protege
- Un compromiso de una aplicación que se convierte en el compromiso de todo el servidor.
- Un servicio expuesto al mundo que solo necesitaba responder a un país.
- Una falta de memoria que se convierte en un problema de storage.
- Un parcheo secuestrado por un mirror externo.
En la práctica
Política por país, demostrada desde fuera. Cuando endurecimos las listas de bloqueo de países en nuestros pares de firewalls públicos, el cambio fue primero al nodo en standby, se verificó que ambos nodos eran idénticos y el resultado se probó desde varios países antes de darse por terminado.
Un sistema de pruebas que responde a un solo país. Un cliente necesitaba un sistema de staging accesible únicamente desde su propio país. El conjunto de reglas se construyó por cliente, con bloqueos explícitos sobre todo lo demás, colocado deliberadamente en relación con las reglas generales de amenazas, y demostrado desde dentro y desde fuera de ese país.
Por qué EuroVPS
- SELinux se mantiene en enforcing. Corregimos la política, no desactivamos la protección.
- Un firewall de host y un par de perímetro de alta disponibilidad en cada servicio público.
- Política por país y por red probada desde fuera después de cada cambio.
- Sin swap en las VM: los problemas de memoria se resuelven con memoria.
- Nuestro propio mirror de paquetes, para que el parcheo nunca espere a nadie.
Preguntas frecuentes
El fabricante de mi aplicación dice que desactive SELinux. ¿Lo harán? No. Escribiremos la política que su aplicación necesita. Según nuestra experiencia, casi siempre es un cambio pequeño y preciso.
¿Pueden restringir mi servicio a determinados países? Sí. Allowlist o blocklist, en el perímetro, probada desde fuera una vez aplicada.
¿Por qué mi VM no tiene swap? Porque el swap sobre flash enterprise compartido hace que un servidor sea lento e impredecible en lugar de resolver el problema real. Si su carga de trabajo necesita más memoria, dimensionamos la máquina para ello o le ayudamos a ajustar la aplicación.
¿Puedo tener inicios de sesión con contraseña para mi equipo? El acceso administrativo es por clave. Le ayudaremos a configurar claves para todas las personas que necesiten acceso.
Si quiere una plataforma bastionada por defecto, no bajo petición, hable con un ingeniero.
Su próximo socio de infraestructura
Veamos su infraestructura.
Cuéntenos qué ejecuta hoy y qué necesita mejorar. Un ingeniero revisará su solicitud y le ayudará a planificar el siguiente paso.
+357 222 32280
Empecemos por su infraestructura.
Un poco de contexto nos ayuda a empezar la conversación adecuada.