{"id":55733,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","title":{"rendered":"Evoluci\u00f3n del Firewall de Aplicaciones Web: de cortafuegos de red a sistemas de protecci\u00f3n en la nube con aprendizaje autom\u00e1tico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En nuestro material anterior sobre la tem\u00e1tica de la nube, hemos contado<\/a><\/noindex>, abordamos c\u00f3mo proteger los recursos de TI en la nube p\u00fablica y por qu\u00e9 los antivirus tradicionales no son del todo adecuados para estas necesidades. En este post, continuaremos el tema de la seguridad en la nube y hablaremos sobre la evoluci\u00f3n del WAF y sobre qu\u00e9 es mejor elegir: hardware, software o la nube.\u00a0<\/b><\/p>\n

\"Evoluci\u00f3n
\n<\/p>\n

\u00bfQu\u00e9 es un WAF?<\/h3>\n

\nM\u00e1s del 75% de los ataques de hackers se dirigen a vulnerabilidades en aplicaciones y sitios web: tales ataques suelen ser indetectables para la infraestructura y los servicios de seguridad inform\u00e1tica. Las vulnerabilidades en aplicaciones web, a su vez, conllevan riesgos de compromiso y fraude de cuentas y datos personales de usuarios, contrase\u00f1as, y n\u00fameros de tarjetas de cr\u00e9dito. Adem\u00e1s, las vulnerabilidades en un sitio web sirven como punto de entrada para los atacantes a la red corporativa.<\/p>\n

El Firewall de Aplicaciones Web (WAF) es una pantalla de protecci\u00f3n que bloquea ataques a aplicaciones web: inyecciones SQL, scripting entre sitios, ejecuci\u00f3n remota de c\u00f3digo, ataques por fuerza bruta y eludir la autorizaci\u00f3n (auth bypass). Esto incluye ataques que utilizan vulnerabilidades de d\u00eda cero. Los firewalls de aplicaciones proporcionan protecci\u00f3n monitoreando el contenido de las p\u00e1ginas web, incluyendo HTML, DHTML y CSS, y filtrando solicitudes potencialmente maliciosas por HTTP\/HTTPS.
\n<\/a><\/noindex><\/p>\n

\u00bfCu\u00e1les fueron las primeras soluciones?<\/h3>\n

\nLos primeros intentos de crear un Firewall de Aplicaciones Web se realizaron a principios de la d\u00e9cada de 1990. Se conoce al menos a tres ingenieros que trabajaron en este \u00e1mbito. El primero es el profesor de ciencias de la computaci\u00f3n Gene Spafford de la Universidad de Purdue. \u00c9l describi\u00f3 la arquitectura de un firewall de aplicaciones con proxy y la public\u00f3 en 1991 en su libro \u00abSeguridad UNIX en la pr\u00e1ctica\u00bb<\/a><\/noindex>.<\/p>\n

El segundo y el tercero fueron expertos en seguridad inform\u00e1tica, William Cheswick y Marcus Ranum de Bell Labs. Ellos desarrollaron uno de los primeros prototipos de firewalls de aplicaciones. Su difusi\u00f3n fue gestionada por la empresa DEC, que lanz\u00f3 el producto bajo el nombre SEAL (Secure External Access Link). <\/p>\n

Pero SEAL no era una soluci\u00f3n WAF completa. Era un firewall de red cl\u00e1sico con funcionalidad mejorada \u2014 la capacidad de bloquear ataques a FTP y RSH. Por esta raz\u00f3n, el primer WAF considerado hoy en d\u00eda es un producto de Perfecto Technologies (m\u00e1s tarde Sanctum). En 1999, la empresa ha presentado<\/a><\/noindex> el sistema AppShield. En ese momento, Perfecto Technologies estaba desarrollando soluciones de ciberseguridad para el comercio electr\u00f3nico, y el p\u00fablico objetivo de su nuevo producto eran las tiendas en l\u00ednea. AppShield pod\u00eda analizar las solicitudes HTTP y bloquear ataques basados en pol\u00edticas de ciberseguridad din\u00e1micas.<\/p>\n

Casi al mismo tiempo que AppShield (en 2002), apareci\u00f3 el primer WAF de c\u00f3digo abierto. Este fue ModSecurity<\/a><\/noindex>. Se cre\u00f3 con el objetivo de popularizar las tecnolog\u00edas WAF y todav\u00eda es mantenido por la comunidad IT (aqu\u00ed est\u00e1 su el repositorio en GitHub<\/a><\/noindex>). ModSecurity bloquea ataques a aplicaciones, bas\u00e1ndose en un conjunto est\u00e1ndar de expresiones regulares (firmas) \u2014 herramientas para verificar solicitudes seg\u00fan un patr\u00f3n \u2014 OWASP Core Rule Set<\/a><\/noindex>.<\/p>\n

Como resultado, los desarrolladores lograron su objetivo: comenzaron a aparecer nuevas soluciones WAF en el mercado, incluidas aquellas basadas en ModSecurity.<\/p>\n

Tres generaciones \u2014 ya una historia<\/h3>\n

\nSe suelen distinguir tres generaciones de sistemas WAF, que han evolucionado a medida que han avanzado las tecnolog\u00edas.<\/p>\n

Primera generaci\u00f3n<\/b>. Funciona con expresiones regulares (o gram\u00e1ticas). Esto incluye ModSecurity. El proveedor del sistema estudia los tipos de ataques a aplicaciones y forma patrones que describen solicitudes leg\u00edtimas y potencialmente maliciosas. El WAF se compara con estas listas y decide qu\u00e9 hacer en cada situaci\u00f3n, ya sea bloquear el tr\u00e1fico o no.<\/p>\n

Un ejemplo de detecci\u00f3n basada en expresiones regulares es el ya mencionado proyecto Core Rule Set<\/a><\/noindex> de c\u00f3digo abierto. Otro ejemplo es Naxsi<\/a><\/noindex>, que tambi\u00e9n es de c\u00f3digo abierto. Los sistemas con expresiones regulares tienen una serie de desventajas, en particular, al detectar una nueva vulnerabilidad, el administrador debe crear reglas adicionales manualmente. En el caso de una infraestructura IT a gran escala, puede haber miles de reglas. Gestionar tal cantidad de expresiones regulares es bastante complicado, sin mencionar que su verificaci\u00f3n puede disminuir el rendimiento de la red.<\/p>\n

Las expresiones regulares tambi\u00e9n tienen un alto nivel de falsos positivos. El famoso ling\u00fcista Noam Chomsky propuso una clasificaci\u00f3n de gram\u00e1ticas, dividi\u00e9ndolas en cuatro niveles de complejidad condicional. Seg\u00fan esta clasificaci\u00f3n, las reglas de los cortafuegos se pueden describir solo con expresiones regulares que no contemplan desviaciones del patr\u00f3n. Esto significa que los atacantes pueden f\u00e1cilmente \"enga\u00f1ar\" a un WAF de primera generaci\u00f3n. Uno de los m\u00e9todos para combatir esto es agregar caracteres especiales a las solicitudes a las aplicaciones que no afectan la l\u00f3gica de los datos maliciosos, pero infringen la regla de firma.<\/p>\n

\"Evoluci\u00f3n
\n
\nSegunda generaci\u00f3n<\/b>. Para superar los problemas relacionados con el rendimiento y la precisi\u00f3n de los WAF, se desarrollaron cortafuegos para aplicaciones de segunda generaci\u00f3n. Estos incluyen analizadores responsables de detectar tipos de ataques muy espec\u00edficos (sobre HTML, JS, etc.). Estos analizadores trabajan con tokens especiales que describen las solicitudes (por ejemplo, variable, cadena, desconocido, n\u00famero). Las secuencias de tokens potencialmente maliciosas se extraen a una lista separada, que se verifica regularmente con el sistema WAF. Este enfoque se present\u00f3 por primera vez en la conferencia Black Hat 2012 a trav\u00e9s de C\/C++\u00a0la biblioteca libinjection<\/a><\/noindex>, que permite identificar inyecciones SQL.<\/p>\n

En comparaci\u00f3n con los WAF de primera generaci\u00f3n, los analizadores especializados pueden funcionar m\u00e1s r\u00e1pido. Sin embargo, no han resuelto las dificultades asociadas con la configuraci\u00f3n manual del sistema ante la aparici\u00f3n de nuevos ataques maliciosos. <\/p>\n

\"Evoluci\u00f3n
\n
\nTercera generaci\u00f3n<\/b>. La evoluci\u00f3n en la l\u00f3gica de detecci\u00f3n de tercera generaci\u00f3n radica en la aplicaci\u00f3n de m\u00e9todos de aprendizaje autom\u00e1tico, permitiendo acercar al m\u00e1ximo la gram\u00e1tica de detecci\u00f3n a la gram\u00e1tica real de SQL\/HTML\/JS de los sistemas protegidos. Esta l\u00f3gica de detecci\u00f3n es capaz de adaptar la m\u00e1quina de Turing para abarcar gram\u00e1ticas recursivamente enumeradas. Anteriormente, la tarea de crear una m\u00e1quina de Turing adaptable era irresoluble, hasta que se publicaron las primeras investigaciones sobre m\u00e1quinas neuronales de Turing.<\/p>\n

El aprendizaje autom\u00e1tico ofrece una oportunidad \u00fanica para adaptar cualquier gram\u00e1tica para abarcar cualquier tipo de ataque sin necesidad de crear listas de firmas manualmente, como se requer\u00eda en la detecci\u00f3n de primera generaci\u00f3n, y sin desarrollar nuevos tokenizadores\/parsers para nuevos tipos de ataques, como las inyecciones de Memcached, Redis, Cassandra, SSRF, como exig\u00eda la metodolog\u00eda de segunda generaci\u00f3n. <\/p>\n

Al combinar las tres generaciones de l\u00f3gica de detecci\u00f3n, podemos dibujar un nuevo diagrama, donde la detecci\u00f3n de tercera generaci\u00f3n se representa con un contorno rojo (fig. 3). Esta generaci\u00f3n incluye una de las soluciones que implementamos en la nube junto a 'Onsec', desarrollador de la plataforma de protecci\u00f3n adaptativa de aplicaciones web y API Valarm. <\/p>\n

Ahora en la l\u00f3gica de detecci\u00f3n se utiliza la retroalimentaci\u00f3n de la aplicaci\u00f3n para la autoajuste. Dentro del aprendizaje autom\u00e1tico, este ciclo de retroalimentaci\u00f3n se llama 'refuerzo'. Por lo general, hay uno o varios tipos de este refuerzo:<\/p>\n