Cómo se comprometen realmente los sitios, y cómo no ser la víctima fácil.
En seguridad, la causa supuesta suele ser «no pasa nada». Así es como se comprometen realmente los sitios, por qué lo alto de esa lista es evitable, y cómo se demuestra desde fuera que una corrección cerró la puerta.
En este artículo 4 secciones
- En seguridad, la causa supuesta es «no pasa nada». La mayoría no sabe que ha sido comprometida.
- Nuestra monitorización y nuestros feeds de threat intelligence están conectados para abrir el ticket, así que el primer mensaje suele ser nuestro. Detectarlo primero es el trabajo.
- Los sitios se comprometen de formas aburridas. El software obsoleto y las cosas que se dejaron abiertas sin querer encabezan la lista, y son exactamente lo que detectan una auditoría antes de la puesta en producción y el parcheo continuo.
- Encontrar la brecha es solo la mitad. Cuando cerramos una, demostramos que la puerta está cerrada volviendo a atacar desde una dirección en la que no confiamos. Si aún podemos llegar, no está arreglado.
Hay una señal en cada llamada de seguridad. La causa supuesta del cliente suele ser la peor que existe: no pasa nada. No llamaron porque algo pareciera raro. Llamaron porque se lo dijimos nosotros. Para cuando una brecha es visible para la persona propietaria del sitio, normalmente ya ha ocurrido.
En seguridad, la causa supuesta es «no pasa nada»
“quote: En seguridad, la causa supuesta del cliente suele ser «no pasa nada». No sabían que habían sido comprometidos. attribution: EUROVPS SECURITY”
Esa es toda la diferencia. No que las brechas no ocurran. Ocurren, en todas las plataformas, en todo tipo de sitios. La diferencia es quién lo ve primero: una capa de detección que vigila las firmas de un compromiso, o un feed de threat intelligence que marca tráfico que no debería existir, mientras el propio panel del sitio sigue en verde. Nuestra monitorización y esos feeds están conectados para abrir el ticket, y por eso el primer mensaje suele ser nuestro.
Cómo se comprometen realmente los sitios
Quite la versión de película y las formas en que se comprometen realmente los sitios son aburridas, y se repiten. Esta es la clasificación, de más a menos frecuente. Nada en lo alto de esta lista es ingenioso.
Software obsoleto o al final de su vida
La forma de entrar más frecuente, con mucha diferencia. Una aplicación con una vulnerabilidad públicamente conocida, expuesta a internet, con años de retraso en parches. Expuesta a internet y con años de retraso en parches es todo lo que hace falta. El exploit está en la estantería. No se necesita ingenio.
Algo que se dejó abierto sin querer
No hace falta exploit. La puerta simplemente estaba abierta. Un almacén de datos enlazado a todas las interfaces de red sin autenticación. Un archivo de configuración o de depuración legible por todo el mundo. Un CMS que filtra sus nombres de usuario por una API abierta. Un subdominio de staging olvidado que sigue respondiendo. Nadie forzó la entrada. Entraron andando.
El origen alcanzable detrás de la CDN
El sitio está detrás de una CDN, pero el servidor real sigue respondiendo directamente si alguien lo encuentra, y su dirección suele estar en el propio DNS de correo del dominio. La puerta principal está vigilada mientras la de atrás está calzada.
Fuerza bruta de credenciales sin defensa en la capa 7
Una página de login sin nada delante en la capa de aplicación, martilleada hasta que algo cede. Un firewall de capa 3/4 lo deja pasar sin más: para un filtro de puertos, parece tráfico normal hacia un puerto que tiene que seguir abierto.
Credenciales débiles, reutilizadas o expuestas sin MFA
Una contraseña que se filtró en otro sitio, reutilizada aquí, sin un segundo factor que la vuelva inútil. La cerradura estaba bien. La llave ya había sido copiada.
Spam saliente desde una cuenta ya comprometida
A menudo la primera señal externa de una brecha que ya ha ocurrido. La cuenta no es el objetivo. Es la plataforma de lanzamiento, y el spam es el humo, no el fuego.
Phishing e ingeniería social
La capa humana. Sin ningún fallo de software. Simplemente convencieron a alguien de entregar las llaves.
Mire los dos primeros. Software obsoleto y cosas que se dejaron abiertas sin querer. Ninguno es un ataque ingenioso. Ambos son exactamente lo que una auditoría disciplinada antes de la puesta en producción y el parcheo continuo detectan antes de que nadie pruebe el picaporte. Ese es todo el argumento a favor de la managed security. La mayoría de las intrusiones no son intrusiones. Son entradas andando. Y la entrada andando es evitable.
Detectarlo primero es el trabajo. Demostrar que está cerrado es la diferencia.
Encontrar la brecha es la mitad del trabajo. La mitad que casi nadie hace es demostrar que la corrección realmente aguantó. Cuando cerramos un compromiso, no nos creemos la palabra del panel de que el puerto está cerrado. Volvemos a atacar el origen como lo haría un atacante: desde una máquina en otro de nuestros datacenters, por una salida en la que nunca se le dijo al firewall que confiara. Si nuestro propio escáner aún puede llegar, no está arreglado. Solo cuando la puerta está cerrada desde fuera, desde una dirección en la que no confiamos, la llamamos cerrada.
“quote: El trabajo no es solo arreglar la brecha. Es detectarla primero, y después demostrar desde fuera que la puerta está cerrada. attribution: EUROVPS SECURITY”
Ese método, volver a atacar su propio origen desde una posición no confiable y confirmar lo que un atacante vería realmente, es una disciplina propia y tiene su propio artículo. Cómo demostramos que la puerta está cerrada recorre el playbook completo.
Siete formas de no ser la víctima fácil
Nada en lo alto de esa clasificación necesita un atacante genial. Lo que significa que la mayor parte es evitable con no ser el objetivo fácil. Siete hábitos, en el orden en que dan resultado.
Parchee o retire
Si está expuesto a internet y sin mantenimiento, es un pasivo. Actualícelo o apáguelo. No hay una tercera opción que acabe bien.
Suponga que el origen será encontrado
Restrínjalo a los rangos de IP de la CDN para que solo la CDN pueda alcanzarlo, y deje de filtrar su dirección en su DNS de correo. Un origen oculto no está oculto si su propio DNS lo anuncia.
Un firewall L3/4 no es un WAF
El filtrado de puertos no lee peticiones. La fuerza bruta, la inyección y el abuso en la capa de aplicación pasan todos por puertos que tiene que dejar abiertos. Necesita una defensa que inspeccione la capa 7.
Audite antes de declararlo terminado
«Funciona» no es «está cerrado». Compruebe qué está expuesto, qué es legible por todo el mundo, qué sigue enlazado a la internet pública, antes de la puesta en producción, no después de que llegue el aviso.
Suponga que las credenciales se filtran. Hágalas inútiles fuera de la whitelist.
MFA en todas partes, y restrinja las rutas sensibles a direcciones conocidas. Una contraseña robada no debería abrir nada por sí sola.
Vigile al vigilante
Una monitorización que se queda ciega y sigue informando en verde es peor que ninguna monitorización, porque compra una calma falsa. Confirme que el detector realmente puede ver.
Demuestre la corrección desde fuera
La única prueba que cuenta es la mirada del atacante. Vuelva a atacar desde una dirección en la que no confíe y confirme que la puerta está cerrada.
Respuestas directas
¿Cómo se hackean realmente los sitios web en el managed hosting?+
Sobre todo de dos formas aburridas. Software obsoleto o al final de su vida con una vulnerabilidad públicamente conocida, expuesto a internet, y cosas que se dejaron abiertas sin querer: un almacén de datos sin autenticación, un archivo de configuración legible por todo el mundo, un subdominio de staging olvidado. Los exploits ingeniosos están muy abajo en la lista. La mayoría de las intrusiones son entradas andando.
¿Cómo sabría siquiera que mi sitio ha sido comprometido?+
A menudo no lo sabría, y esa es la cuestión. Nuestra monitorización y nuestros feeds de threat intelligence están conectados para abrir el ticket, así que el primer mensaje sobre un compromiso suele ser nuestro. La causa supuesta del lado del cliente suele ser «no pasa nada». El spam saliente o un aviso de un tercero es con frecuencia la primera señal externa, y para entonces ya ha ocurrido.
¿Mi servidor es seguro si tiene un firewall?+
Un firewall en la capa 3/4 filtra puertos. No lee peticiones. La fuerza bruta de credenciales, la inyección y el abuso en la capa de aplicación viajan todos por puertos que tiene que dejar abiertos, así que para él parecen tráfico normal. Un firewall no es un WAF. Detener eso necesita una defensa que inspeccione la capa 7.
¿Pueden los atacantes encontrar mi servidor de origen si está detrás de una CDN?+
Con frecuencia, sí. La CDN solo ayuda si el origen no puede alcanzarse directamente, y la dirección real del origen suele filtrarse en el propio DNS de correo del dominio. Restrinja el origen a los rangos de IP de la CDN y deje de anunciarlo en el DNS, o la puerta principal vigilada tendrá la de atrás calzada.
En el managed hosting, ¿quién es responsable de parchear mis aplicaciones?+
La plataforma y la aplicación son trabajos distintos, y el hueco entre ambos es donde se comprometen los sitios. Nosotros mantenemos la plataforma bastionada y auditamos antes de la puesta en producción. Pero una aplicación al final de su vida con una vulnerabilidad conocida es un riesgo compartido. El valor de lo gestionado es que una auditoría disciplinada antes de la puesta en producción y el parcheo continuo detectan la mayor parte antes de que nadie pruebe el picaporte.
¿No está seguro de qué está expuesto? Pregunte antes de que lo descubra otro.
Tráigalo a un ingeniero, no a una cola de tickets. Comprobamos qué es alcanzable desde fuera, le decimos con claridad qué cerrar, y después demostramos que está cerrado.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero