Cuando se habla de cortafuegos de aplicaciones, se tiende a agrupar una serie de conceptos diferentes bajo un mismo término. Sin embargo, no todos los cortafuegos son iguales, y es importante comprender las diferencias entre ellos, especialmente si se quiere determinar qué protección necesita realmente una aplicación.
Analicémoslo. Hay tres capas principales de seguridad de aplicaciones que debes conocer: WAF, en la aplicación y en el núcleo. RASP y algunos ADR se encuentran en la aplicación, mientras que los ADR basados en eBPF de nivel inferior se encuentran en el núcleo. Todos ellos tienen el mismo objetivo general de evitar que le sucedan cosas malas a tu aplicación, pero la forma en que lo hacen es muy diferente. En resumen, WAF ve la solicitud, en la aplicación ve el código y en el núcleo 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 WAF, RASP, ADR y eBPF, en qué es más eficaz cada uno de ellos, y le ayudaremos a decidir cuál necesita.
WAF VS RASP VS ASP: ¿Cómo funcionan las tres capas de seguridad de las aplicaciones?
Las herramientas de seguridad de aplicaciones operan en tres niveles diferentes, y cada una detecta cosas que las otras no pueden.
WAF: seguridad perimetral
Los WAF se encuentran completamente fuera de su aplicación e inspeccionan el tráfico HTTP entrante antes de que llegue a su aplicación. No tienen contexto de aplicación, pero son excelentes para amenazas de gran volumen.
Seguridad en tiempo de ejecución dentro de la aplicación: dentro de la aplicación
Los instrumentos de seguridad integrados en la aplicación se conectan directamente a su aplicación. Se conectan a la ejecución de su código, rastrean cómo fluyen las entradas del usuario a través de su aplicación y pueden bloquear los ataques en el momento exacto en que se vuelven peligrosos, antes de que una carga maliciosa llegue al controlador de su base de datos o genere un shell. Como tienen un contexto completo de la aplicación, son precisos. Las herramientas RASP, una subcategoría de ADR, entran en esta categoría.
Seguridad en tiempo de ejecución en el núcleo: por debajo de la aplicación
Las herramientas de seguridad en tiempo de ejecución integradas en el núcleo se sitúan por debajo de la aplicación, a nivel del sistema operativo. En lugar de conectarse al código de la aplicación, supervisan todas las llamadas al sistema realizadas por cada proceso en el host. No tienen ni idea de lo que hace la lógica de la aplicación, pero ven todo a nivel del sistema operativo, incluyendo lo que ocurre después de que un atacante haya entrado. Las herramientas ADR basadas en eBPF entran en esta categoría.
Primero analizaremos WAF, luego in-app e in-kernel a través de la lente de RASP y ADR.
¿Qué es WAF?
Un WAF ( firewall de aplicaciones web firewall de aplicaciones) se encuentra 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 insustituibles 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 gran volumen y fuerza bruta. Cloudflare, por ejemplo, es extremadamente eficaz a la hora de absorber ataques a gran escala antes de que interactúen con su infraestructura. Además, son fáciles de implementar. En la mayoría de los casos, solo hay que cambiar el DNS o el proxy, sin necesidad de escribir código ni instalar nada dentro de la aplicación. Los WAF también son muy configurables con reglas personalizadas, listas de permisos y ajuste de reglas, y también se puede decidir si bloquear algo sospechoso o simplemente detectarlo.
El problema es que un WAF no tiene ni idea de lo que ocurre una vez que una solicitud atraviesa la puerta. Puede detectar una carga sospechosa, pero no puede decirte si esa carga va a hacer realmente algo peligroso, ya que no tiene ni idea de lo que tu aplicación va a hacer realmente con una solicitud. Ve el tráfico entrante, compara los patrones con lo que se ha configurado para detener y decide si bloquearlo o no.
Como resultado, los falsos positivos son un problema real y pueden bloquear fácilmente las solicitudes. Un usuario puede buscar algo que se parezca a SQL y ser bloqueado, mientras que un atacante inteligente codifica su carga útil de forma diferente y logra pasar. Y si un WAF quiere detener a un usuario malintencionado, bloquea su IP. Entonces, un atacante puede simplemente usar una VPN para evitarlo. Pero si luego intentas bloquear todo el tráfico de la VPN, también bloqueas a los usuarios reales.
Como resultado, el ajuste del WAF es un proceso continuo en el que se endurecen las reglas, se vigilan los falsos positivos y se relajan cuando es necesario. Es una de las razones por las que los WAF pueden requerir mucho mantenimiento en comparación con los RASP, que necesitan mucho menos ajuste continuo porque cuentan con 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 medidas de seguridad en tiempo de ejecución que residen dentro de la aplicación y la supervisan desde dentro mientras se ejecuta, en lugar de situarse fuera de la aplicación e inspeccionar el tráfico entrante como un WAP.
Para entender por qué esto es importante, es necesario conocer los sumideros. Un sumidero es una función —en su código, una biblioteca o un módulo integrado— en la que la entrada del usuario deja de ser un dato y se ejecuta como algo significativo. Podemos tomar como ejemplo una inyección SQL. Un atacante introduce código malicioso en un campo de formulario, que fluye a través de su aplicación, llega al controlador de su base de datos (algunos db.query()), y en ese momento deja de ser texto y se convierte en un comando. Esa función de consulta es el sumidero. Lo que hacen las herramientas de seguridad integradas en la aplicación, como RASP, es conectarse a esos sumideros y observar cómo se mueven las entradas a través de la aplicación, rastreándolas hasta la función peligrosa.
Dado que estas herramientas integradas en la aplicación se ejecutan, bueno, dentro de tu aplicación, saben cuál es la entrada, de dónde proviene y adónde va. En lugar de adivinar si ' O 1=1-- es un ataque o una cadena de búsqueda legítima, una herramienta integrada en la aplicación sabe que esta cadena específica proviene de req.body.usuario, se concatenó sin desinfectar y está a punto de alcanzar un pg.query() ¡Bloquéalo!
Las tasas de falsos positivos son mucho más bajas que las de WAF y ADR basados en eBPF, ya que no se trata solo de una comparación ciega de patrones. Puede bloquear una ID de usuario en lugar de solo una IP, por lo que un atacante no puede simplemente utilizar una VPN. Y como rastrea el flujo de datos en lugar de comparar firmas conocidas, puede detectar nuevas cargas de ataque que nadie ha visto antes. ¡Sólida cobertura de día cero para ataques de clase inyección!
RASP y los ADR integrados en la aplicación también cubren las dependencias de terceros. Puede limpiar su propio código a la perfección, pero si una biblioteca que está utilizando tiene una vulnerabilidad, eso está fuera de su control (si su escáner SCA tampoco la detectó). RASP opera a nivel de sumidero, independientemente de la procedencia del código.
La principal limitación de la seguridad dentro de la aplicación es que, si un atacante elude por completo el tiempo de ejecución, mediante un complemento nativo o una llamada directa al sistema, los ganchos 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 después. Ahí es donde entra en juego la tercera capa.
Ejemplos: Aikido Zen ( versión de código abierto y versión de pago)
¿Qué es el ADR?
ADR (detección y respuesta de aplicaciones) es la categoría moderna más amplia en la que se incluye RASP. Todo RASP es ADR, pero no todo ADR es RASP. El término ADR abarca cualquier herramienta que supervise y responda a los ataques en tiempo de ejecución, ya sea desde dentro de la aplicación o por debajo de ella.
En la práctica, las herramientas ADR se dividen en dos tipos. El ADR integrado en la aplicación (lo que siempre ha sido RASP) se encuentra directamente en su aplicación y tiene un contexto completo a nivel de código. Todo lo que se ha tratado en la sección anterior sobre RASP en relación con la seguridad integrada en la aplicación se aplica aquí. El ADR también implica un alcance más amplio que el RASP, ya que mientras que el RASP es principalmente una herramienta de bloqueo, el ADR también abarca 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 está moviendo la categoría.
El otro tipo de ADR, el ADR en el núcleo o el ADR basado en eBPF, adopta un enfoque diferente para proteger las aplicaciones. En lugar de conectarse a la aplicación, se sitúa en el nivel del núcleo de Linux y supervisa todas las llamadas al sistema realizadas por todos los procesos del host. No sabe nada sobre la lógica de la aplicación, pero lo ve todo a nivel del sistema operativo.
Una vez que un atacante ha generado un shell, el ADR en el núcleo proporciona el siguiente nivel de visibilidad tras la explotación que el ADR en la aplicación no puede ver. El ADR en el núcleo ve todos los comandos que se ejecutan dentro de ese shell, como lecturas de archivos, llamadas de red y movimientos laterales. Si un atacante elude por completo el tiempo de ejecución, el ADR sigue viendo el execve independientemente de cómo se haya desencadenado. En la práctica, el escenario más habitual para las aplicaciones Node.js es que un complemento nativo malicioso se cuele a través de un ataque a la cadena de suministro (una dependencia comprometida que incluye código nativo que su tiempo de ejecución no inspecciona).
eBPF (Extended Berkeley Packet Filter) es la tecnología subyacente del kernel que impulsa las herramientas ADR en el kernel. eBPF le permite adjuntar un programa de supervisión seguro al kernel de Linux que puede observar eventos específicos que ocurren a nivel del sistema operativo, sin tocar el kernel en sí. Normalmente, si desea añadir supervisión o lógica personalizadas a nivel del núcleo, tendría que modificar directamente el código fuente del núcleo (arriesgado y complejo) o escribir un módulo del núcleo (también arriesgado, ya que un error puede bloquear todo el sistema). eBPF evita eso permitiéndole inyectar pequeños programas en el núcleo que se ejecutan en un entorno aislado. Estos programas observan llamadas al sistema específicas e informan a la herramienta ADR, que luego decide si permite o bloquea la acción.
La desventaja del ADR integrado en el núcleo, al igual que el WAF, es que no tiene contexto de aplicación. Ve llamadas al sistema sin procesar, como «el proceso 4821 ejecutó un programa», pero no tiene ni idea de qué solicitud HTTP o usuario lo activó. Sin ese contexto, la seguridad en el núcleo tiene que funcionar en su lugar con políticas, que son reglas como «este proceso nunca debe generar un shell» o «este contenedor nunca debe escribir en este directorio». Eso funciona para detectar infracciones claras, pero lo hace bastante binario, por lo que no tiene matices.
Para ataques de clase inyección, como la inyección SQL, el ADR en el núcleo es prácticamente ciego. Cuando el ataque llega a la capa de llamadas al sistema, la carga útil SQL es solo bytes sin procesar dentro de un búfer de red. Los exploits en tiempo de ejecución son otro punto ciego. Algunos ataques se lanzan completamente dentro del tiempo de ejecución 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 la aplicación para su configuración. Sin embargo, tiene más requisitos y necesita una configuración más compleja que WAF o RASP, ya que las herramientas ADR suelen necesitar un kernel 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 visto muchos términos: WAF, RASP, ADR, eBPF, in-app, in-kernel. La respuesta corta es que lo que se quiere es protección en más de una capa. La respuesta larga depende de qué capas. En lo que respecta a RASP frente a ADR, RASP es una subcategoría de ADR, por lo que la pregunta es: ¿quieres seguridad in-app, seguridad in-kernel o ambas?
Las diferentes capas son complementarias, no competitivas, porque cada una capta cosas que las otras no pueden. Por eso, la respuesta a «¿WAF o RASP?» suele ser «ambas», y añadir ADR en el núcleo te proporciona la cobertura posterior a la explotación y a nivel del núcleo que completa el panorama.
Las tres capas plantean preguntas fundamentalmente diferentes:
- WAF: «¿Esta solicitud HTTP coincide con un patrón de ataque conocido?»
- Seguridad en la aplicación (RASP y ADR): «¿Esta entrada del usuario está a punto de activar una función peligrosa en mi aplicación?».
- Seguridad en el núcleo (ADR): «¿Este proceso acaba de hacer algo que no debería haber hecho a nivel del sistema operativo?».
TL;DR: Primero, consiga un WAF y una herramienta de seguridad integrada en la aplicación. Más adelante, si necesita un procesamiento específico a nivel del kernel, adquiera un ADR basado en eBPF.
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, es natural que tenga el menor número de falsos positivos en comparación con las otras dos. Mientras que protección en tiempo de ejecución dentro de la aplicación protección en tiempo de ejecución manejar la mayoría de los ataques a nivel de aplicación o de inyección, se necesita un WAF para ataques de gran volumen, como los DDoS. Dado que los WAF se encuentran fuera de la aplicación, pueden manejar miles de solicitudes de bots antes de llegar a su aplicación y tocar esos recursos, y esto no requiere mucho contexto para funcionar. Juntos, la seguridad dentro de la aplicación, como Aikido Zen, combinada con un WAF, cubrirán la gran mayoría de los problemas que encontrará.
Si se encuentra en un punto en el que necesita una visibilidad completa tras la explotación, le preocupa el movimiento lateral o necesita aplicar políticas a nivel del núcleo en múltiples procesos, es el momento de pensar en añadir ADR en el núcleo. Es la herramienta adecuada para una configuración de seguridad más madura, aunque no necesariamente la primera opción a la que recurrir. Algunas herramientas ADR integradas en aplicaciones cubren más que otras. Aikido Zen, por ejemplo, supervisa 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 núcleo más complicada, los equipos pueden configurar Zen con un solo npm install y una línea de código.
Lo único que cubre el ADR en el núcleo más allá de Zen es lo que ocurre después de que se haya generado un shell y el atacante esté operando a nivel del sistema operativo. Por lo tanto, Zen no sustituirá a eBPF si necesita esa visibilidad completa tras la explotación y la aplicación de políticas a nivel del kernel en todos los procesos, pero para la mayoría de los equipos, cubre la superficie de ataque más importante (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 del Aikido: el ADR moderno integrado en la aplicación
Aunque tienen objetivos similares, no todas las herramientas de seguridad integradas en aplicaciones son iguales. Los nuevos ADR , como Zen, firewall integrado en la aplicación de código abierto firewall integrado en la aplicación de Aikido, se sitúan en el ámbito de la seguridad integrada en aplicaciones, pero cubren aspectos que una herramienta RASP estándar no cubre.
Zen proporciona todo el contexto de aplicación de los RASP tradicionales, como el rastreo de contaminaciones, el bloqueo a nivel de sumidero, el reconocimiento de ID de usuario y un bajo índice de falsos positivos, pero, como ADR moderno, Zen también supervisa la actividad saliente de la misma forma que lo hace el ADR integrado en el núcleo. Esto incluye todas las consultas SQL, comandos de shell, lecturas de archivos y llamadas HTTP salientes que realiza su aplicación. Su algoritmo de vulnerabilidad es determinista desde la primera solicitud, por lo que no hay problemas de arranque en frío ni mantenimiento continuo de reglas como ocurre con otros RASP.
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 (creado en Rust) y aplica automáticamente el ámbito de los inquilinos. Si una consulta carece de un filtro de inquilino o utiliza un ID de inquilino incorrecto, Zen genera un error antes de enviarla. Las IDOR (referencias directas a objetos inseguras) son la causa más común de fugas de datos entre inquilinos en SaaS multitenant, y son muy difíciles de detectar en las revisiones de código. Zen hace que sea imposible implementarlas accidentalmente.
Más información: Prevención de ataques de día cero para Node.js con Aikido Zen
Preguntas Frecuentes
¿Qué es un WAF?
Un WAF ( firewall de aplicaciones web firewall de aplicaciones) se encuentra fuera de su aplicación e inspecciona el tráfico HTTP entrante en busca de patrones de ataque conocidos. Es especialmente eficaz a la hora de gestionar amenazas volumétricas, como ataques DDoS y tráfico de bots, pero no tiene visibilidad sobre lo que realmente hace su aplicación 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. Supervisa cómo fluyen las entradas del usuario a través de su código y bloquea los ataques en el punto en el que se vuelven peligrosos: el sumidero. Dado que tiene un contexto completo de la aplicación, es mucho más preciso que un WAF para los ataques de clase inyección.
¿Cuál es la diferencia entre WAF y RASP?
Un WAF se encuentra fuera de su aplicación y bloquea el tráfico basándose en patrones. Un RASP se encuentra dentro de su aplicación y bloquea los ataques basándose en lo que su código está a punto de hacer con la información introducida por el usuario. Los WAF son más fáciles de implementar y son ideales para amenazas volumétricas. Los RASP tienen menores índices de falsos positivos y una mejor cobertura para ataques de inyección y zero-days.
¿Necesito tanto un WAF como un RASP?
Sí, son complementarios, no competitivos. Un WAF se encarga de la protección a nivel de borde y del tráfico volumétrico. Un RASP se encarga de los ataques de clase 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 frente a RASP?
En general, ADR abarca herramientas que proporcionan seguridad tanto dentro de la aplicación como dentro del núcleo. RASP se refiere a herramientas dentro de la aplicación, y son un subconjunto de ADR. RASP y ADR dentro de la aplicación son técnicamente el mismo enfoque, solo que con diferentes nombres a lo largo del tiempo. La etiqueta ADR es más reciente y amplia. A veces, ADR se utiliza como abreviatura o de forma intercambiable con eBPF, herramientas ADR basadas en el núcleo. Los términos RASP y ADR varían ligeramente dependiendo de a quién se le pregunte. Tenga esto en cuenta a medida que investigue más sobre el tema.
¿Qué es ADR/eBPF en la seguridad de las aplicaciones?
ADR (detección y respuesta de aplicaciones) cubre tanto la seguridad dentro de la aplicación como dentro del núcleo. Las herramientas ARD en el núcleo, como Tetragon o Falco, operan a nivel del núcleo de Linux, supervisando todas las llamadas al sistema en todos los procesos del host. Son muy eficaces en cuanto a la visibilidad tras la explotación y la detección de elusiones a nivel del núcleo, pero carecen de contexto de aplicación, lo que las convierte en un complemento de RASP en lugar de un sustituto. eBPF (Extended Berkeley Packet Filter) es la tecnología subyacente del núcleo que impulsa las herramientas ADR en el núcleo.
Si desinfectas todas las entradas correctamente, ¿sigo necesitando RASP?
Sí. La desinfección es difícil de realizar siempre a la perfección. Especialmente si durante el desarrollo no se utilizan herramientas SAST de calidad del código, pueden aparecer errores de seguridad en el código base. No lo considere tanto un sustituto de las buenas prácticas de codificación segura, sino más bien un respaldo en tiempo de ejecución para cuando esas prácticas no son perfectas (lo que, en la práctica, por supuesto, nunca lo son). RASP también detiene los problemas derivados de dependencias de terceros.
