Cuando la gente habla de firewall de aplicaciones, tiende a agrupar un montón de cosas diferentes bajo un mismo paraguas. Pero no todos los firewalls son iguales, y comprender las diferencias entre ellos es importante, especialmente si está tratando de averiguar qué protección necesita realmente su aplicación.
Así que, vamos a desglosarlo. Hay tres capas principales de seguridad de aplicaciones que debe conocer: WAFs, in-app y in-kernel. RASP y algunos ADR son in-app, mientras que los ADR de nivel inferior basados en eBPF son in-kernel. Todos tienen el mismo objetivo general de evitar que le ocurran cosas malas a su aplicación, pero la forma en que lo hacen es muy diferente. En resumen, el WAF ve la solicitud, el in-app ve el código y el in-kernel ve el sistema operativo.
¿Cuál necesita? Bueno, si desea la postura de seguridad más sólida posible, lo más probable es que necesite más de uno. En este artículo, explicaremos qué son los WAFs, RASP, ADR y eBPF, en qué es más eficaz cada uno y le ayudaremos a decidir cuál de ellos necesita.
WAF VS RASP VS ASP: ¿Cómo funcionan las tres capas de seguridad de aplicaciones?
Las herramientas de seguridad de aplicaciones operan en tres niveles diferentes, y cada una detecta lo que las otras no pueden.
WAF: seguridad perimetral
Los WAF se sitúan completamente fuera de su aplicación, inspeccionando el tráfico HTTP entrante antes de que llegue a su aplicación. Sin contexto de aplicación, pero excelentes para amenazas de alto volumen.
Seguridad en tiempo de ejecución en la aplicación: dentro de la aplicación
Los instrumentos de seguridad en la aplicación se integran directamente en su aplicación. Se integran en la ejecución de su código, rastrean cómo fluye la entrada del usuario a través de su aplicación y pueden bloquear ataques en el punto exacto donde se vuelven peligrosos, antes de que una carga maliciosa llegue a su controlador de base de datos o genere un shell. Al tener un contexto de aplicación completo, es preciso. Las herramientas RASP, una subcategoría de ADR, entran en esta categoría.
Seguridad en tiempo de ejecución en el kernel: por debajo de la aplicación
Las herramientas de seguridad en tiempo de ejecución en el kernel se sitúan completamente por debajo de su aplicación, a nivel del sistema operativo. En lugar de integrarse en el código de la aplicación, observa cada llamada al sistema (syscall) realizada por cada proceso en el host. No tiene idea de lo que está haciendo la lógica de su aplicación, pero ve todo a nivel del sistema operativo, incluyendo lo que sucede después de que un atacante ya ha accedido. Las herramientas ADR basadas en eBPF entran en esta categoría.
Primero analizaremos los WAF, luego la seguridad en la aplicación y en el kernel a través de la lente de RASP y ADR.
¿Qué es un WAF?
Un WAF (firewall de aplicaciones web) se sitúa fuera de su aplicación, en el perímetro. Antes de que una solicitud llegue a su aplicación, el WAF la intercepta y la compara con una lista de patrones de ataque conocidos, como cadenas de inyección SQL, encabezados maliciosos o URL sospechosas. Si algo coincide con un patrón, se bloquea.
Donde los WAF son realmente irremplazables es en los ataques volumétricos, como el tráfico DDoS, las inundaciones de bots y los scrapers. Los WAF están diseñados para ataques de alto volumen y fuerza bruta. Cloudflare, por ejemplo, es extremadamente eficaz absorbiendo ataques a gran escala antes de que interactúen con su infraestructura. También son fáciles de desplegar. Principalmente un cambio de DNS o proxy, sin código que escribir, nada que instalar dentro de su aplicación. Los WAF también son muy configurables con reglas personalizadas, listas de permitidos y ajuste de reglas, y también puede decidir si bloquear algo sospechoso o simplemente detectarlo.
El inconveniente es que un WAF no tiene idea de lo que sucede una vez que una solicitud atraviesa la puerta. Puede detectar una carga útil de aspecto sospechoso, pero no puede decirle si esa carga útil realmente va a hacer algo peligroso porque no tiene idea de lo que su aplicación realmente va a hacer con una solicitud. Ve el tráfico entrante, lo compara con los patrones para los que ha sido configurado para detener, y decide si bloquearlo.
Como resultado, los falsos positivos son un problema real, y puede bloquear solicitudes en exceso fácilmente. Un usuario puede buscar algo que se parezca a SQL y ser bloqueado, mientras que un atacante inteligente codifica su carga útil de manera diferente y logra pasar. Y si un WAF quiere detener a un usuario malicioso, bloquea su IP. Entonces un atacante puede simplemente usar una VPN para eludirlo. Pero si luego intenta bloquear todo el tráfico de la VPN, también bloquea a usuarios reales.
Como resultado, el ajuste de WAF es un proceso continuo donde se ajustan las reglas, se buscan falsos positivos y se relajan donde sea necesario. Es una de las razones por las que los WAF pueden requerir un alto mantenimiento en comparación con RASP, que necesita mucho menos ajuste continuo porque tiene el contexto de la aplicación para tomar mejores decisiones sin intervención manual.
Ejemplos: Cloudflare, AWS WAF, Imperva
Código abierto: ModSecurity (a través de OWASP)
¿Qué es RASP?
RASP (Runtime Application Self-Protection) y ADR en la aplicación son seguridad en tiempo de ejecución que reside dentro de su aplicación y la monitoriza desde dentro mientras se ejecuta, en lugar de situarse fuera de su aplicación inspeccionando el tráfico entrante como un WAF.
Para entender por qué esto es importante, necesita conocer los sinks. Un sink es una función —en su código, una librería o un módulo integrado— donde la entrada del usuario deja de ser datos y se ejecuta como algo significativo. Podemos tomar una inyección SQL como ejemplo. Un atacante introduce código malicioso en un campo de formulario, que fluye a través de su aplicación, llega a su controlador de base de datos (algún db.query()), y en ese punto, deja de ser texto y se convierte en un comando. Esa función de consulta es el sink. Lo que hacen las herramientas de seguridad en la aplicación como RASP es integrarse en esos sinks y observar cómo la entrada se mueve a través de la aplicación, rastreándola hasta la función peligrosa.
Dado que estas herramientas in-app se ejecutan, bueno, dentro de tu aplicación, conocen la entrada, su origen y su destino. En lugar de adivinar si ' OR 1=1-- es un ataque o una cadena de búsqueda legítima, una herramienta in-app sabe que esta cadena específica provino de req.body.user, fue concatenada sin sanitizar y está a punto de alcanzar una pg.query() llamada. ¡Bloquéala!
Las tasas de falsos positivos son mucho más bajas que las de WAF y ADR basado en eBPF porque no se limita a la coincidencia ciega de patrones. Puede bloquear un ID de usuario en lugar de solo una IP, así un atacante no puede simplemente usar una VPN. Y como rastrea el flujo de datos en lugar de buscar firmas conocidas, puede detectar nuevas cargas útiles de ataque nunca antes vistas. ¡Sólida cobertura de día cero para ataques de clase de inyección!
RASP y los ADR in-app también cubren dependencias de terceros. Puedes sanitizar tu propio código perfectamente, pero si una librería que utilizas tiene una vulnerabilidad, eso está fuera de tu control (si tu escáner SCA tampoco la detectó). RASP opera a nivel de sumidero, independientemente del origen del código.
La principal limitación de la seguridad in-app es que si un atacante elude completamente el runtime, a través de un addon nativo o una syscall directa, los hooks nunca se activan. Y una vez que se genera un shell, RASP ve la llamada inicial pero no lo que ocurre dentro de ese shell posteriormente. Ahí es donde entra en juego la tercera capa.
Ejemplos: Aikido Zen (código abierto y versión de pago)
¿Qué es ADR?
ADR (Application Detection and Response) es la categoría moderna más amplia bajo la cual se engloba RASP. Todo RASP es ADR, pero no todo ADR es RASP. El término ADR cubre cualquier herramienta que monitoriza y responde a ataques en tiempo de ejecución, ya sea desde dentro de tu aplicación o completamente por debajo de ella.
En la práctica, las herramientas ADR se dividen en dos tipos. El ADR in-app (lo que RASP siempre ha sido) reside directamente en tu aplicación y tiene un contexto completo a nivel de código. Todo lo cubierto en la sección RASP anterior sobre seguridad in-app se aplica aquí. ADR también implica un alcance más amplio que RASP; mientras que RASP es principalmente una herramienta de bloqueo, ADR abarca también capacidades de detección, visibilidad y respuesta a incidentes. No todas las herramientas ADR hacen todo esto, pero es la dirección en la que se mueve la categoría.
El otro tipo de ADR, el ADR a nivel de kernel, o ADR basado en eBPF, adopta un enfoque diferente para proteger las aplicaciones. En lugar de engancharse a tu aplicación, se sitúa a nivel del kernel de Linux y observa cada syscall realizada por cada proceso en el host. No conoce la lógica de tu aplicación, pero ve todo a nivel del sistema operativo.
Una vez que un atacante ha generado un shell, el ADR a nivel de kernel proporciona el siguiente nivel de visibilidad post-explotación que el ADR in-app no puede ver. El ADR a nivel de kernel ve cada comando que se ejecuta dentro de ese shell, como lecturas de archivos, llamadas de red y movimiento lateral. Si un atacante elude completamente el runtime, ADR sigue viendo la execve independientemente de cómo se haya activado. En la práctica, el escenario más común para las aplicaciones Node.js es un addon nativo malicioso que se introduce a través de un ataque a la cadena de suministro (una dependencia comprometida que incluye código nativo que tu runtime no inspecciona).
eBPF (Extended Berkeley Packet Filter) es la tecnología de kernel subyacente que impulsa las herramientas ADR a nivel de kernel. eBPF permite adjuntar un programa de monitorización seguro al kernel de Linux que puede observar eventos específicos que ocurren a nivel del sistema operativo, sin tocar el propio kernel. Normalmente, si se desea añadir monitorización o lógica personalizada a nivel de kernel, habría que modificar directamente el código fuente del kernel (arriesgado, complejo) o escribir un módulo de kernel (también arriesgado, ya que un error puede colapsar todo el sistema). eBPF lo evita permitiendo inyectar pequeños programas en el kernel que se ejecutan en un entorno aislado. Estos programas observan syscalls específicas e informan a la herramienta ADR, que luego decide si permitir o bloquear la acción.
La desventaja del ADR a nivel de kernel, al igual que WAF, es que no tiene contexto de aplicación. Ve syscalls en bruto, como "el proceso 4821 ejecutó un programa", pero no tiene idea de qué solicitud HTTP o usuario la desencadenó. Sin ese contexto, la seguridad a nivel de kernel tiene que funcionar basándose en políticas, que son reglas como "este proceso nunca debería generar un shell" o "este contenedor nunca debería escribir en este directorio". Esto funciona para detectar violaciones claras, pero lo hace bastante binario, por lo que carece de matices.
Para ataques de clase de inyección como la inyección SQL, el ADR a nivel de kernel está prácticamente ciego. Para cuando el ataque llega a la capa de syscall, la carga útil SQL son solo bytes en bruto dentro de un búfer de red. Los exploits en tiempo de ejecución son otro punto ciego. Algunos ataques se ejecutan completamente dentro del runtime del lenguaje, por lo que nunca crean una operación inusual a nivel del sistema operativo hasta que es demasiado tarde.
A diferencia de las herramientas RASP tradicionales, este tipo de ADR no requiere cambios en el código de tu aplicación para su configuración. Sin embargo, tiene más requisitos y configuración que WAF o RASP, ya que las herramientas ADR generalmente necesitan un kernel de Linux relativamente moderno y privilegios de sistema elevados.
Ejemplos: Tetragon, Falco, KubeArmor (código abierto)
Oligo ADR (comercial)
WAF, RASP, ADR, eBPF: ¿Cuál necesito?
Hasta ahora, hemos revisado muchos términos: WAF, RASP, ADR, eBPF, in-app, a nivel de kernel. La respuesta corta es que se desea protección en más de una capa. La respuesta más larga depende de las capas. Cuando se trata de RASP vs ADR, RASP es una subcategoría de ADR, por lo que la pregunta es: ¿quieres seguridad in-app, seguridad a nivel de kernel, o ambas?
Las diferentes capas son complementarias, no competitivas, porque cada una detecta cosas que las otras no pueden. Por eso, la respuesta a "¿WAF o RASP?" suele ser "ambos", y añadir ADR a nivel de kernel proporciona la cobertura post-explotación y a nivel de kernel que completa el panorama.
Las tres capas plantean preguntas fundamentalmente diferentes:
- WAF: "¿Coincide esta solicitud HTTP con un patrón de ataque conocido?"
- Seguridad integrada en la aplicación (RASP y ADR): "¿Está esta entrada de usuario a punto de alcanzar una función peligrosa en mi aplicación?"
- Seguridad en el kernel (ADR): "¿Acaba de hacer este proceso algo que no debería a nivel del sistema operativo?"
En resumen: Obtenga primero un WAF y una herramienta de seguridad integrada en la aplicación. Obtenga un ADR basado en eBPF más tarde si necesita un procesamiento específico a nivel de kernel.
La seguridad integrada en la aplicación, como RASP, es la única capa que tiene contexto sobre cómo interactúan los datos con la aplicación específica, por lo que es la única capa que puede realizar un bloqueo realmente preciso. Por lo tanto, naturalmente, tiene la menor cantidad de falsos positivos en comparación con las otras dos. Mientras que la protección en tiempo de ejecución integrada en la aplicación puede manejar la mayoría de los ataques a nivel de aplicación o de inyección, se necesita un WAF para ataques de alto volumen, como DDoS. Dado que los WAF se sitúan fuera de la aplicación, pueden manejar miles de solicitudes de bots antes de que lleguen a su aplicación y toquen esos recursos, y esto no requiere una gran cantidad de contexto para funcionar. Juntos, la seguridad integrada en la aplicación como Aikido Zen combinada con un WAF cubrirá la gran mayoría de los problemas que encontrará.
Si se encuentra en el punto en el que necesita visibilidad completa post-explotación, le preocupa el movimiento lateral o necesita aplicar políticas a nivel de kernel en múltiples procesos, es entonces cuando debe considerar añadir un ADR en el kernel. Es la herramienta adecuada para una configuración de seguridad más madura, aunque no necesariamente lo primero a lo que recurrir. Algunas herramientas ADR integradas en la aplicación cubren más que otras. Aikido Zen, por ejemplo, monitoriza la actividad saliente (consultas SQL, comandos de shell, lecturas de archivos y llamadas HTTP salientes) que realiza su aplicación. Y en comparación con una configuración ADR en el kernel más complicada, los equipos pueden configurar Zen con una única npm install y una línea de código.
Lo único que cubre el ADR en el kernel más allá de Zen es lo que sucede después de que ya se ha generado un shell y el atacante está operando a nivel del sistema operativo. Por lo tanto, Zen no reemplazará a eBPF si necesita esa visibilidad completa post-explotación y la aplicación de políticas a nivel de kernel en todos los procesos, pero para la mayoría de los equipos, cubre la superficie de ataque que más importa (ataques de inyección, zero-days y lógica de autorización). Sin embargo, si tiene un RASP diferente que no cubre la actividad saliente y las inyecciones SQL, es posible que necesite eBPF antes.
Zen de Aikido: El ADR moderno integrado en la aplicación
Aunque tienen objetivos similares, no todas las herramientas de seguridad integradas en la aplicación son iguales. Los nuevos ADR como Zen, el firewall de aplicaciones de código abierto de Aikido, se sitúan en el territorio de la seguridad integrada en la aplicación, pero cubren aspectos que una herramienta RASP estándar no.
Zen proporciona el contexto completo de la aplicación de los RASP tradicionales, como el rastreo de taint, el bloqueo a nivel de sink, la conciencia de ID de usuario, los bajos falsos positivos, pero como un ADR moderno, Zen también monitoriza la actividad saliente de la misma manera que lo hace el ADR en el kernel. Esto incluye cada consulta SQL, comando de shell, lectura de archivo y llamada HTTP saliente que realiza su aplicación. Su algoritmo de vulnerabilidad es determinista desde la primera solicitud, por lo que no hay problema de arranque en frío ni mantenimiento continuo de reglas que otros RASP tienen.
Zen también va más allá de los ataques de clase de inyección. Analiza cada consulta SQL en tiempo de ejecución utilizando un analizador SQL completo (construido en Rust) y aplica el alcance de inquilinos automáticamente. Si una consulta carece de un filtro de inquilino o utiliza el ID de inquilino incorrecto, Zen lanza un error antes de que se implemente. Los IDOR (referencias directas inseguras a objetos) son la causa más común de fugas de datos entre inquilinos en SaaS multi-inquilino, y son notoriamente difíciles de detectar en las revisiones de código. Zen hace que sea imposible implementarlos accidentalmente.
Lectura adicional: Prevención de ataques de día cero para Node.js con Aikido Zen
Preguntas Frecuentes
¿Qué es un WAF?
Un WAF (Web Application Firewall) se sitúa fuera de su aplicación e inspecciona el tráfico HTTP entrante en busca de patrones de ataque conocidos. Es particularmente bueno para manejar amenazas volumétricas como ataques DDoS y tráfico de bots, pero no tiene visibilidad de lo que su aplicación realmente hace con una solicitud.
¿Qué es la seguridad RASP?
RASP (Runtime Application Self-Protection) es una herramienta de seguridad que se ejecuta dentro de su aplicación. Monitoriza cómo fluye la entrada del usuario a través de su código y bloquea los ataques en el punto donde se vuelven peligrosos: el sink. Debido a que tiene el contexto completo de la aplicación, es mucho más precisa que un WAF para ataques de clase de inyección.
¿Cuál es la diferencia entre WAF y RASP?
Un WAF se sitúa fuera de su aplicación y bloquea el tráfico basándose en patrones. Un RASP se sitúa dentro de su aplicación y bloquea los ataques basándose en lo que su código está a punto de hacer con la entrada del usuario. Los WAF son más fáciles de implementar y excelentes para amenazas volumétricas. Los RASP tienen tasas de falsos positivos más bajas y una mejor cobertura para ataques de inyección y zero-days.
¿Necesito tanto un WAF como un RASP?
Sí, son complementarios, no compiten. Un WAF gestiona la protección a nivel de borde y el tráfico volumétrico. Un RASP gestiona los ataques de clase de inyección y los zero-days que los WAF suelen pasar por alto. La mayoría de las configuraciones de seguridad maduras utilizan ambos.
¿Qué es ADR vs RASP?
En general, ADR abarca herramientas que proporcionan seguridad integrada en la aplicación o en el kernel. RASP se refiere a herramientas integradas en la aplicación, y son un subconjunto de ADR. RASP y ADR integrado en la aplicación son técnicamente el mismo enfoque, solo diferentes etiquetas a lo largo del tiempo. La etiqueta ADR es más nueva y más amplia. A veces, ADR se utiliza como abreviatura o indistintamente con eBPF, herramientas ADR basadas en el kernel. Los términos para RASP y ADR varían ligeramente dependiendo de a quién le pregunte. Tenga esto en cuenta al investigar más a fondo sobre el tema.
¿Qué es ADR / eBPF en la seguridad de aplicaciones?
ADR (Detección y Respuesta de Aplicaciones) cubre la seguridad tanto en la aplicación (in-app) como en el kernel (in-kernel). Las herramientas ARD in-kernel como Tetragon o Falco operan a nivel del kernel de Linux, monitorizando cada llamada al sistema (syscall) en cada proceso del host. Son potentes en visibilidad post-explotación y en la detección de bypasses a nivel de kernel, pero carecen de contexto de aplicación, lo que las hace complementarias a RASP en lugar de un reemplazo. eBPF (Extended Berkeley Packet Filter) es la tecnología subyacente del kernel que impulsa las herramientas ADR in-kernel.
Si se sanean todas las entradas correctamente, ¿todavía necesito RASP?
Sí. El saneamiento es difícil de realizar siempre a la perfección. Especialmente si las herramientas SAST y de calidad de código no están presentes durante el desarrollo, los fallos de seguridad pueden introducirse en la base de código. Piénselo menos como un reemplazo de buenas prácticas de codificación segura y más como un respaldo en tiempo de ejecución (runtime backstop) para cuando esas prácticas no son perfectas (lo cual, en la práctica, nunca lo son). RASP también detiene los problemas derivados de dependencias de terceros.
